2,000 Greater & Lesser Mysteries/2,000 Greater and Lesser Mysteries.iso/computer/virus/mys00497.txt

Text File | 1994-06-10 | 602.6 KB | 14,334 lines

[ Last modified 23 January 89 - Ken van Wyk ]

Welcome!  This is the  semi-monthly introduction posting   to VIRUS-L,
primarily for the benefit of any newcomers  to the list.   Many of you
have probably already seen  a message (or two...)  much like this, but
it does change from time to time, so I would appreciate it if you took
a couple of minutes to glance over it.



What is VIRUS-L?

It is an electronic mail discussion forum for sharing  information and
ideas about computer  viruses.  Discussions should include   (but  not
necessarily  be limited to): current  events  (virus sightings), virus
prevention    (practical  and   theoretical),    and  virus    related
questions/answers.   The list  is moderated  and digested.  That means
that  any message coming  in gets  sent  to  me,  the  editor.  I read
through the messages and make sure  that they adhere to the guidelines
of the list (see below) and add them to the  next digest.  Weekly logs
of digests are kept by the LISTSERV (see below  for  details on how to
get them).  For  those interested in statistics,  VIRUS-L is now (Jan.
23, 1989) up to 950  direct subscribers.  Of  those, approximately  80
are local redistribution accounts with an unknown number of readers.

As stated above, the list is digested and moderated.  As such, digests
go out when a) there are enough messages for  a digest, and  b) when I
put all incoming (relevant) messages into the digest.  Obviously, this
can   decrease   the  timeliness of urgent    messages such  as  virus
warnings/alerts.  For that, we have a sister list called VALERT-L.  It
is unmoderated  and undigested  - anything  going in  to the list goes
directly  out  to  all  the  subscribers, as  well  as  to VIRUS-L for
inclusion in the  next available  digest.   VALERT-L is for  the  sole
purpose of  rapidly sending out  virus alerts.   Anyone who  does  not
adhere to this  one guideline of  VALERT-L will be immediately removed
from the list.   That is, no news   is good  news.  Subscriptions  and
deletions to  VALERT-L are  handled identically as  those  for VIRUS-L
(see instructions below).


What VIRUS-L is *NOT*?

A place to  spread hype about  computer  viruses;  we already have the
Press for that.  :-) A place to sell things, to panhandle, or to flame
other subscribers.  If anyone *REALLY* feels the need to flame someone
else for something that they may have  said, then the flame  should be
sent directly to that person and/or to the list moderator  (that would
be me, <[e-mail]>).


How do I get on the mailing list?

Well, if you are  reading this, chances are *real  good* that  you are
already on the list.  However, perhaps this  document was given to you
by a friend or colleague...  So, to get onto the VIRUS-L mailing list,
send a mail message to <[e-mail]>.  In the body of the
message, say nothing more than SUB  VIRUS-L your name.  LISTSERV  is a
program which automates mailing lists such as VIRUS-L.  As long as you
are either on BITNET, or any network accessible to BITNET via gateway,
this  should work.  Within  a short time, you will  be  placed  on the
mailing list, and you will get confirmation via e-mail.


How do I get OFF of the list?

If, in  the unlikely  event, you should  happen  to want to be removed
from  the   VIRUS-L     discussion    list,   just    send   mail   to
<[e-mail]>  saying  SIGNOFF VIRUS-L.   People, such as
students, whose accounts are going to be closed (for example, over the
summer...) - PLEASE signoff of  the list before  you leave.  Also,  be
sure to send your signoff request to the LISTSERV and  not to the list
itself.  Note that the appropriate node  name is LEHIIBM1, not LEHIGH;
we have a node called LEHIGH, but they are *NOT* one and the same.


How do I send a message to the list?

Just send electronic mail  to  <[e-mail]>  and it  will
automatically be sent to the editor for possible inclusion in the next
digest to go out.


What does VIRUS-L have to offer?

All  VIRUS-L  digests  are stored in  weekly   log  files which can be
downloaded by  any user on  (or off) the mailing  list.  Note that the
log files contain all of the digests from a particular week.  There is
also a small archive  of some of the  public anti-virus programs which
are currently available.  This  archive, too,  can be accessed  by any
user.  All  of this is  handled automatically by the  LISTSERV here at
Lehigh University (<[e-mail]>).


How do I get files (including log files) from the LISTSERV?

Well, you will first want  to know what  files are   available on  the
LISTSERV.  To do this, send mail  to <[e-mail]> saying
INDEX VIRUS-L.   Note   that filenames/extensions  are  separated by a
space, and not by a period.  Once  you  have decided which file(s) you
want,  send   mail to  <[e-mail]> saying  GET filename
filetype.  For example, GET VIRUS-L LOG8804 would get the  file called
VIRUS-L LOG8804 (which happens to be the  monthly  log of all messages
sent to VIRUS-L during   April,  1988).  Note  that, starting  June 6,
1988, the logs  are weekly.  The  new file format is  VIRUS-L LOGyymmx
where yy is  the year  (88, 89, etc.),  mm is the  month, and x is the
week (A, B, etc.).  Readers who prefer digest format lists should read
the  weekly logs  and sign   off   of   the  list  itself.  Subsequent
submissions to the list should be sent to me for forwarding.

Also available is a  LISTSERV at SCFVM which  contains more anti-virus
software.   This  LISTSERV  can  be  accessed  in  the  same manner as
outlined   above,   with  the    exceptions  that    the  address   is
<[e-mail]> and that the commands to  use are INDEX PUBLIC
and GET filename filetype PUBLIC.


What is uuencode/uudecode, and why might I need them?

Uuencode and uudecode are two programs which convert binary files into
text (ASCII) files and back  again.  This  is so binary  files can  be
easily transferred via  electronic mail.  Many  of  the files on  this
LISTSERV  are binary files  which are stored in uuencoded  format (the
file types will be  UUE).  Both uuencode  and  uudecode  are available
from the LISTSERV.  Uudecode is available in BASIC and in Turbo Pascal
here.  Uuencode is available in Turbo  Pascal.  Also, there  is a very
good binary-only uuencode/uudecode  package on the LISTSERV  which  is
stored in uuencoded format.


Why have posting guidelines?

To keep the discussions on-track with what the list is intended to be;
a vehicle for virus  discussions.   This will keep the network traffic
to a minimum and, hopefully, the quality of the content of the mail to
a maximum.



What are the guidelines?

     Try to keep messages relatively short and to the  point, but with
     all relevant information included.   This serves a  dual purpose;
     it keeps network traffic to  a necessary minimum, and it improves
     the likelihood of readers reading your entire  message.

     Personal information and  .signatures  should   be  kept to   the
     generally accepted maximum of 5   lines of text.  The editor  may
     opt  to shorten  some lengthy   signatures (without deleting  any
     relevant  information, of course).  Within   those  5 lines, feel
     free to be a bit, er, creative if you wish.

     Anyone  sending  messages   containing, for  example,   technical
     information should   *PLEASE*  try  to  confirm their  sources of
     information.  When possible, site  these sources.  Speculating is
     frowned upon -  it merely  adds confusion.  This editor does  not
     have the time to confirm all contributions  to  the list, and may
     opt to discard messages which do not appear to have valid sources
     of information.

     All messages sent  to  the list  should have appropriate  subject
     lines.  The subject lines should  include the type of computer to
     which the message  refers, when applicable.  E.g., Subject: Brain
     virus detection (PC).  Messages without appropriate subject lines
     *STAND A GOOD CHANCE OF NOT BEING INCLUDED IN A DIGEST*.

     As already  stated, there will  be no flames  on the list.   Such
     messages will be discarded.

     The same goes for any commercial plugs or panhandling.

     Submissions  should be directly   or indirectly   related  to the
     subject of computer viruses.  This one is particularly important,
     other subscribers really  do not want to  read  about things that
     are  not  relevant  -    it only  adds to  network    traffic and
     frustration for the people reading the list.

     Responses to queries should be sent  to the author of  the query,
     not to the entire list.  The author should then send a summary of
     his/her responses to the list at a later date.

     "Automatic  answering machine" programs (the ones  which reply to
     e-mail for you when you are gone) should be set to *NOT* reply to
     VIRUS-L.  Such  responses sent to  the entire list are  very rude
     and will be treated as such.

     When sending in a submission, try  to see whether or  not someone
     else  may have just said  the same  thing.   This is particularly
     important when  responding to postings   from someone else (which
     should be sent to that person *anyway*).  Redundant messages will
     be sent back to their author(s).

Thank-you for your time  and for your  adherence to these  guidelines.
Comments and suggestions, as always, are invited.  Please address them
to me, <[e-mail]> or <[e-mail]>.


Ken van WykVIRUS-L Digest             Wednesday, 1 Feb 1989        Volume 2 : Issue 33

Today's Topics:
'Virus' term usage
Re: CP/M Viruses
Re: Virus Terminology
Re: Origin of the term `virus'
Virus epidemics.  Is the hype too much?
Categorizing viruses

---------------------------------------------------------------------------

Date:     Tue, 31 Jan 89 10:02:08 EST
From: Jefferson Ogata (me!) <[e-mail]>
Subject:  'Virus' term usage

One simple reason the term 'virus' wouldn't be used of code before 5
or so years ago is that until about 9 or 10 years ago, the general
public wasn't all that familiar with the details of how a biological
virus works.  And those who did know probably wouldn't bother using
the term, since few would understand why it would be appropriate.

You'll also find that in the Middle Ages, not many people used the
term even for biological viruses.  :-)

- - Jeff Ogata

------------------------------

Date:         Tue, 31 Jan 89 10:22:13 EST
From: Art Larky  <AIL0@LEHIGH>
                215 Packard Building 19
Subject: Re: CP/M Viruses

  I don't know of any CP/M viruses and I suspect there were few or
none.  The current virus outbreaks are based upon a couple of things
which weren't applicable to CP/M:
  (1) There wasn't as much trading of files and disks because there
wasn't as many personal computers and Bulletin Boards around.
  (2) CP/M systems were not accessible at the hardware level to the
same extent as PC's because everyone's hardware was different.  My
BIOS is similar to those of other persons, but the underlying ROM
routines are ones that I wrote myself; the disk addresses were chosen
by me; my screen display is similar to some, but not all CP/M systems.
In fact, my screen display is different from the one I started with
and I had to change my programs and my ROM because of it.
  (3) There weren't as many assembly language programmers out there
because there weren't as many computers by a factor of 100,000 or
1,000,000 to 1.  The more people who have computers to play with and
know how to program, the greater the likelihood of there being a
combination of weirdo and programming in one sicko.

  All of which supports what I said before, you can protect yourself
from some viruses by making your system different; e.g., your own
names for files like autoexec.bat and command.com.

Art Larky
CSEE Dept
Lehigh University   I know I'm not speaking for Lehigh University,
                    there's no reason for you to think so either.

------------------------------

Date:     Tue, 31 Jan 89 10:32:16 EST
From:     Jefferson Ogata (me!) <[e-mail]>
Subject:  Re: Virus Terminology

J. Yeidel writes that 'virulent' is an inappropriate word for a virus
that spreads rapidly within a system, and that 'extremely contagious'
would be better.  I must disagree with the second point, as 'extreme-
ly contagious' implies that the virus spreads from system to system
quickly.  In fact, a virus's contagion depends on its contact with the
outside world, which is usually dependent on human factors -- does a
person swap disks often? etc.

Regarding 'benign', I think most people use it in a relative sense; no
one really means the virus does no damage, although viruses could
exist that do no damage (even as far as destroying themselves to avoid
wasting humans' time).  However, 'benign' could be applied to the
'virulent' problem, in the sense it is used in describing tumors:
namely, a 'benign' virus would be one that doesn't spread throughout a
machine, and a 'malignant' virus would be one that does.  At pres-
ent, 'malignant' cannot be used easily because of its ambiguity in
this regard.  And a 'benign virus' may truly be a contradiction in
terms, I suppose.  However, a virus could be 'benign' under some
circumstances and 'malignant' under others.

'Misimpressions'?  Surely you mean 'false impressions'. :-)

- - Jeff

[Ed. I think that all of this points out yet again that there is
*much* confusion over the terminology that's used - not only by the
media, but us, the computer users/professionals.  Developing a clearly
defined set of terms and making everyone understand and use them would
obviously be great, but would prove to be logistically impossible.  If
we're all careful in our use of the terminology, and we even
explicitly define what we mean whenever using terms that could be
misconstrued, then perhaps we could try to eliminate *some* of the
confusion.  Maybe it would be best to refrain from using such terms as
"virulent", "benign", "virus", etc.?  Suggestions?]

------------------------------

Date: Tue, 31 Jan 89 11:39:52 PST
From:     [e-mail]
Subject: Re: Origin of the term `virus'

I remember 8 years ago coming across the term `worm' for the first
time: it was a program (developed at Xerox, I believe) that soaked up
spare cpu cycles on networked machines to perform some lengthy,
non-critical task (disk defragmentation or computing pi); there was no
derogatory connotation.  Around the same time I read a book, "The
Adolescence of P-1" (forget the author) about a program that took off
across the network in much the same was as the RTM worm, although this
one became sentient and altered technical specs for power supplies at
IBM so that it could turn itself on, survive IPLs, etc, when the
service rep installed the mod.

Peter Scott ([e-mail])

------------------------------

Date:     Tue, 31 Jan 89 12:26:33 PST
From:     <[e-mail]>  (Commander Spock)
Subject:  Virus epidemics.  Is the hype too much?

I just wanted to throw up an interesting idea that other developers
and myself have been talking about for the last few weeks.

Our group theorized about the recent virus epidemics that are
currently spreading around for both IBM as well as Macintosh
computers.  Theory: there is big money (currently) for writing
ATNI-VIRUS software to "protect" users against the nasty 'ol viri,
right?  How do we know (users and developers alike) that these
software makers of ANTI-VIRUS programs are not the true culprits
behind the distribution (initially or re-distributed) of the various
viri that's been creating havoc for the rest of the world (those
affected).  I admit though, it's jumping to conclusions.  But has
anyone else considered this possibility?  How would we know if our
software is "safe" anymore?  The problem is, we cannot.

Pleaase note that I did not infer *ANY* organizational names of any
nature, just merely threw up the possibility that we may be cutting
our throats by attempting to protect ourselves.  Paranoia is the
largest factor that causes viri to be passed around.  Fear of
contamination, fear of destruction; all of this creates a unique blend
of craziness.

Think it over before you purchase your next software package that
guarantees that it's "safe" of any bugs or viri.

Robert S. Radvanovsky
California Polytechnic University
Pomona, California

P.S.  I will be willing to discuss this with those who feel that this
      viri epidemic has gone a bit out of hand.  Should you feel that you
      would like to contact me, please send appropriate mailings to:

         [e-mail]  <- Internet
         [e-mail]                  <- BITNET

      I've finally found out what our correct addresses are.  Mind
      you, the views expressed here are "theories", nothing more.

------------------------------

Date: Wed, 1 Feb 89 07:58:18 est
From: ubu![e-mail]
Subject: Categorizing viruses

A while back (October 31, 1988 in log file VIRUS-L LOG8810E), Len
Levine ([e-mail]) suggested denoting viruses which make
use of features in an operating system as "Feature Exploiting
Viruses", and viruses which make use of bugs as "Error Exploiting
Viruses".  I think that it could be a good idea to classify viruses in
a manner such as this.  However, I would like to expand on Professor
Levine's idea a bit, if I may; viruses which use hardware (I use the
term "hardware" very loosely - meaning anything which bypasses the
operating system, including the BIOS) to propagate should be
classified as "Hardware Exploiting Viruses".

Hardware Exploiting Viruses (HEVs) would thus be isolated to PCs and
other (expletive deleted) computers that have no sort of hardware
protection in the form of, for example, privileged commands for
accessing i/o devices.  An example would be the Brain virus which uses
ROM BIOS routines to write to the boot sector.  This would not work if
the hardware restricted BIOS/hardware access to the privileged
instructions (callable only by the operating system), assuming the OS
is functioning properly.  These viruses could be stopped by adopting
computer architectures which provide such hardware security.

Error Exploiting Viruses (EEVs) would be caused by (presumably) bugs
in the operating system, such as undocumented system calls or even
documented system calls which perform in an unexpected (by the
manufacturer) manner.  A hypothetical example here might be a system
call to write to disk which, when given "appropriate" parameters,
allows the calling routine to write to the boot sector due to a
programming error in the call.  These viruses would probably be the
toughest of the three to stop since the bugs would generally only
become evident when programs like the Internet Worm bring them to
light.  The Internet Worm is a non-hypothetical example of an EEV.
Extensive (read: costly) quality control in the form of testing could
reduce the instances of EEVs.

Finally, Feature Exploiting Viruses (FEVs) would take advantage of
procedural shortcomings such as lax usage of file read/write
permissions on a system which would allow data to move from one
filespace to another.  Such a virus could propagate even on a system
which has the potential for neither HEVs nor EEVs.  Rather, it would
be up to the system administration to establish proper operating
procedures, such as file permissions.  An example of an FEV is the
Lehigh Virus, which made use of MS-DOS operating system calls (INT
21H) to attach itself to COMMAND.COM files; this could be prevented by
using the MS-DOS file attribute of READ-ONLY.

It would, of course, be possible for a virus to be made up of a
combination of HEV, EEV, and FEV code.  The Internet Worm, for
example, used several attack methods (sendmail bug, finger bug, etc.);
it could well have been the case that these attack methods each fell
into different categories.  The Lehigh Virus could also fall into more
than one category since it used MS-DOS to propagate, but used a lower
level (Absolute Disk Write) routine to destroy disks.

Why bother with categorizing viruses?  To learn more about them and to
be able to disseminate information (fixes, etc.) effectively.  Of
course, that's just my opinion...  Anybody have anything to add or
change?

Ken van Wyk

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest             Wednesday, 1 Feb 1989        Volume 2 : Issue 34

Today's Topics:
Re: anti-virus viruses
Request for info on possible Mac virus.
Re: Origin of the term `virus'
Re: "FRG Nazi virus" posting / apology-correction
Re: MacWrite bombed by a virus? (from this issue)
Malicious program classification
MIS "Virus Briefing"
FSP_15 (IBM Anti-Viral Software) bug??? (PC)

---------------------------------------------------------------------------

Date:         Wed, 1 Feb 1989 09:28 EST
From:         Bruce Ide <[e-mail]>
Subject:      Re: anti-virus viruses

     One of these days I'm going to have to dig up my research
paper...  Sorry guys, Not yet. Yo! Commander Spock! That's a scary
idea you've come up with. Lets not try to spread that one about in
case no one has thought of it, ok? Now then, it seems to me that the
hardest bit of writing a virus is getting the damn thing to spread. So
if you can kill its spread abilities, you've killed the virus. But
what if we took a "live" virus, mangled its spread abilities a bit,
and then let the thing go with "instructions" to seek other viruses
like itself and copy it's spread abilities over their own. Then at a
certian date, have the lot of them "kill" themselves? You'd still have
a lot of copies out there until the date, maybe doing damage, but if
there was no other way to pull it off, you'd have a population
control.
                                      -Grey Fox

[Ed. The idea of using anti-virus viruses (somewhat of an oxymoron)
was kicked around some time back; the more-or-less unanimous feeling
of VIRUS-L readers at the time was that it is a very bad idea.  Aside
from setting a bad precedent, it has the distinct possibility of
backfiring if someone alters your anti-virus virus to do something
that you hadn't intended for it to do.  Comments?]

------------------------------

Date:     Wed,  1 Feb 89 10:37 EST
From:     Cincinnati Bengals. <[e-mail]>
Subject:  Request for info on possible Mac virus.

     On a Macintosh we've got here in the Academic computing center at
Xavier, we've got Macwrite on a hard-drive.  Whenever I've tried to
startup Macwrite, I get a system error with the ID of 02.  I remember
reading in one of the recent digests that there apparently was a virus
that caused this to happen.  Unfortunately, I deleted those messages
from my account concerning that topic.  Could anyone please tell me if
this is true, and if so, what can be done about it?

Thanks,

Tom Kummer

Acknowledge to:  [e-mail]

[Ed. See Joe McMahon's reply later in this issue.]

------------------------------

Date: Wed, 01 Feb 89 08:32:09 -0800
From: James M Galvin <[e-mail]>
Subject: Re: Origin of the term `virus'

> I remember 8 years ago coming across the term `worm' for the first
> time: it was a program (developed at Xerox, I believe) that soaked up
> spare cpu cycles on networked machines to perform some lengthy,
> non-critical task (disk defragmentation or computing pi); there was no
> derogatory connotation.

See Communications of the ACM, March 1982, v25 n3, 'The "Worm"
Programs--- Early Experience with a Distributed Computation'.
Interestingly, the article is immediately followed by "Self-Assessment
Procedure IX", a self-assessment procedure dealing with ethics in
computing.

Jim

------------------------------

From: J.D. Abolins <[e-mail]>
Date: 1 Feb 89
Subject: Re: "FRG Nazi virus" posting / apology-correction

Ken's addition to my posting about the relevance of another posting
was appropriate. I rechecked the messages and found that the original
posting was citing another writer's usage of the term virus.  My
apologies about the light flame.

Also for any offline e-mail, my BITNET address is OJA @ NCCIBM1.
(Since everything is entered manually at the keyboards, I sometimes
slip up.)

------------------------------

Date:         Wed, 01 Feb 89 11:28:03 EST
From:         Joe McMahon <[e-mail]>
Subject:      Re: MacWrite bombed by a virus? (from this issue)

Well, you could possibly have any number of problems, not all of them
virus-related.

1) Your hard disk is getting an unreported read error on MacWrite.
   Duplicate the file and see if the copy will run OK. If so, run
   your hard disk's diagnostics and see if they come out OK. If not,
   call your dealer and take the drive in for service.
2) Your copy of MacWrite is bad. Replace it from a LOCKED, KNOWN-CLEAN
   copy and try it again.
3) Your System file is bad. Replace it in the same way.
4) You have an INIT or CDEV in the System folder which does not let
   MacWrite initialize properly. Move all of your INIT and CDEV files
   into a folder inside the System folder called "Disabled INITs" or
   something like that. If MacWrite runs after you reboot, try taking
   them out 1 at a time until MacWrite breaks again.
5) You have a known virus. Try running VirusDetective(tm) 2.0 against
   your hard disk. You will want to create another boot disk by copying
   a known-clean System to a blank disk and installing VirusDetective
   there. If you find a known virus, run the proper disinfectant (if
   one exists) to get rid of it. If it's the INIT 29 virus, VirusDetective
   will report it, and can remove it from your non-application files.
   You will have to restore your applications and System from known-clean
   copies.
6) You have an unknown, new virus. Run Interferon 3.1 or Virus Rx 1.4
   to look for possible infections. Then replace the possibly-infected
   files from known-clean originals.

Please drop me a note directly if you get to step 5 without fixing the
problem. Also, it would be interesting to know if any of the following
things happen:

1) Locked disks, when inserted, get the "This disk needs minor repairs"
   dialog. If so, you could have the INIT 29 virus, which I think is
   the one you are thinking about.
2) Printing of large documents fails at irregular intervals. This could
   be several of the viruses, INIT 29, Scores, Hpat, or nVIR.

 --- Joe M.

------------------------------

Date:         Wed, 01 Feb 89 12:31:42 ECT
From:         Ken Hoover <[e-mail]>
Subject:      Malicious program classification

  Ken van Wyk has a very good point.  The distinction between
Error-exploiting, Feature-exploiting, and Hardware-exploiting programs
is an important one.

  A suggestion for virus classification:

  A kind of "standard notation" should be agreed apon which would tell
one the type of program and the way it operates in a single sequence
of characters.  The basis for such a system could be three kinds of
programs - Trojans, worms, and viruses -- standard definitions,
nothing new here; and three methods of activity - hardware, error, and
feature exploitation, as Ken suggested.

  If we use a three-letter code for each major type:

      VIR   - Virus
      WOR   - Worm
      TRO   - Trojan Horse program

  And a single character for the mechanism used:

      e     - error-exploiting
      f     - feature-exploiting
      h     - hardware-exploiting

  The combination <fVIR> would say a lot more than just "well, it
propogates itself through its use of the XXX operating system".  Most
MS-DOS programs fall into the fVIR or hTRO categories, and
CHRISTMA.EXEC would be a fWOR (as far as I know) under this notation.

  eWOR would quickly describe the RTM worm.

  This is only a suggested format for such a classification.
Unfortunately, the nVIR macintosh virus kind of throws a wrench into
the works, and I've left out other aspects that could be covered, such
as timed-dormancy, relative nastiness, the type of systems affected,
etc.  This could, however, be a starting point.

                                             - Ken Hoover

UG Consultant
SUNY-Binghamton
Binghamton, NY USA.
Disclaimer: The opinions are my own.  I don't get paid enough to
            represent my employers'.

------------------------------

Date:     Wed,  1 Feb 89 08:43 MDT
From:     "David D. Grisham" <[e-mail]>
Subject:  MIS "Virus Briefing"

Has anyone else planned to attend any of the "virus Briefings" given
by MIS, with Dr. Cohen?  I'm interested in going to the Dallas
presentation if there will be others in the field who can share
experiences and knowledge.  I doubt that a one day briefing will be
that beneficial on it's own.

dave
*-----------------------------------------------------------------------*
| Dave  Grisham                                                         |
| Senior Staff Consultant/Virus Security        Phone [phone]    |
| Information Resource Center                                           |
| Computer & Information Resources & Technology                         |
| University of New Mexico                      USENET [e-mail]|
| Albuquerque, New Mexico  87131                BITNET DAVE@UNMB        |
*-----------------------------------------------------------------------*

------------------------------

Date:     WED FEB 01, 1989 15.21.05 EST
From:     "David A. Bader" <[e-mail]>
Subject:  FSP_15 (IBM Anti-Viral Software) bug??? (PC)

 I have been using Flu_Shot 1.5 (by Ross Greenberg) and am a lot
happier with this version than the previous, 1.4, because the new
version doesn't check CMOS ram.  However, I have noticed that using
DOS 3.3's PRINT command flags as a TSR by FSP_15 and hangs my 286
clone.  Anyone else use FSP_15????

- -David Bader
 DAB3@LEHIGH

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest              Friday, 3 Feb 1989          Volume 2 : Issue 35

Today's Topics:
Hardware lock (PC)
Re: Anti-virus viruses
The Media and Viruses
Review of antenna program
Ethical issues.
Gatekeeper Report (Mac)
nVIR Assassin... (Mac)
VIRUS WARNING: Lehigh Virus version II (PC)

---------------------------------------------------------------------------

Date:         Wed, 01 Feb 89 16:06:25 CST
From:         James Ford <[e-mail]>
Subject:      Hardware lock (PC)

On a computer with a hard drive, is there any way to (hardware) fix
drive "A" so that the computer will always boot from "C" and yet still
have the use of "A"?  (boot from C always, read/write from A and C)

This may/may not be the correct list to post this to, but I would be
interested in your comments.  (I guess you could stop SOME destructive
programs from spreading this way....)

                           James Ford
                           [e-mail]

------------------------------

Date: Wed, 1 Feb 89 17:50 EST
From: "Mark H. Anbinder" <[e-mail]>
Subject: Re: Anti-virus viruses

One of the ways viruses cause problems is the incidence of accidental
memory-related or incompatibility-caused crashes or similar
situations, simply when they propogate.  Viruses don't need to
intentionally DO something to cause a disk crash or a system crash.

An anti-virus virus would probably cause the same types of problems as
it replicated itself trying to seek out nasties.  It would be nearly
impossible to write such a program that guarded against MOST possible
incompatibilities or memory-management problems, much less against ALL
possible such problems.

Releasing an anti-virus virus upon the world would be similar to the
MacMag virus, which was (theoretically) intended to bring the possible
threat of viruses to the attention of the computing world.  It would
also be similar to the motive some people claim for Robert Morris (one
fellow Cornellian of whom I am NOT proud), of warning people of what a
virus might do if someone MEAN had written it.  It would be
irresponsible in the extreme, and would, most likely, cause more
problems than it would solve, even if no one tried to modify it to be
intentionally harmful.

Mark H. Anbinder
THCY@CRNLVAX5
[e-mail]
Department of Media Services
Cornell University

------------------------------

Date:         Thu, 02 Feb 89 02:46:38 EST
From:         Greg Brail <[e-mail]>
Subject:      The Media and Viruses

There's been a lot of complaining recently about how "The Media" has
been misleading the public about viruses. As a semi-legitimate member
of The Media and as someone who considers himself knowledgeable about
computers, I think some clarification is in order.

Basically, reporters try to write stories that people are going to
want to read. If a story for a non-technical publication gets bogged
down in techno-speak, readers can just as easily read something else.
Writing an accurate article about a technical subject like computer
viruses that the average reader can understand can be difficult, to
say the least.

I know this because I just wrote an article about viruses for the
Brown Daily Herald, the student newspaper here. Perhaps I should
assume that Brown students would have an easier time with such an
article than an "average person." I didn't.

In my article, I referred to the Internet worm as a "virus." The day
the article ran, I read in this mailing list that the proper term for
the program was "worm," not "virus." Had I known that, I would have
corrected the terminology in the article.

But the truth is that it probably wouldn't have made much of a
difference.  To the "average person," a virus is a nasty program that
spreads itself from one computer to another and can do bad things.
That's probably all anyone needs to know.

What computing professionals must understand is that they must be
careful when explaining viruses, or any computer-related issue for
that matter, to a reporter. Even if the reporter doesn't ask, "What's
a virus," you should probably explain it anyway. If a reporter asks
you about the "Internet virus," you should point out that that program
was a worm, not a virus. Reporters don't (usually) make things up. If
you don't give them the correct information, they will assume
something that looks like a virus is, in fact, a virus, whether
they're right or not.

I, too, objected to Newsweek's insinuation that the games spreading
through Germany are viruses, although a one-sentence clarification
near the top of the article would have been fine. I also wondered why
the New York Times and other publications didn't realize that when
people hear that "defense department computers were the victim of a
virus," the think that the computers that launch nuclear missiles were
infected.  And the improper use of the term "hacker" really ticks me
off.

However, the truth is that many journalists are not stupid, ignorant,
or "J-school morons." The best rule for journalists writing about
technical issues is to pretend you don't know anything so your sources
will explain it for you. When talking to journalists, computing
professionals should use the same rule. Don't assume the reporter
knows everything about computers, unless you know that particular
reporter's work. Take the time to clarify what you're talking about.
Many reporters will not stop you if you go too fast, although they
should.

Of course, none of this can happen if the computing community cannot
decide upon and spread the word about the proper definition of "virus"
and other terms. Unfortunately, today's computer users have to know
how to protect themselves from viruses. If the computing community
takes the responsibility of spreading accurate information to
reporters, good reporters will take the responsibility of spreading it
to the public.

Greg Brail
[e-mail]
[e-mail]
P.O. Box 1020
Brown University
Providence, RI 02912

------------------------------

Date:       Thu, 2 Feb 89 10:32:18 GMT
From:       David.J.Ferbrache <[e-mail]>
Subject:    Review of antenna program

[Ed. The following message was sent to the United Kingdom distribution
of VIRUS-L.  Apologies to our UK readers who are reading this for the
second time.]

For anyone interested, there was an Antenna presentation on Computer
viruses on BBC2 last night. Here is a brief review of the material
covered. I guess anyone interested in obtaining a transcript of the
program should contact the BBC.

This program provided an overview of the topic of computer viruses,
the risk and the possible cures. The concept of a computer virus was
explained using the traditional biological analogy, by both Dr A
Solomon (IBMPCUG) and Ian MacKay a biologist from Glasgow University.
Parallels were drawn between the AIDS virus' ability to disguise
itself by changing surface characteristics and that of the computer
virus by changing host program.  (This ability is extended in newer
viruses such as the 1701-Blackjack virus in which the majority of the
virus object code is encrypted when on secondary storage).

Examples were presented of infection of IBM PC compatibles (by the
Italian virus), the Apple Mac (by nVIR a) and the Amiga (by the SCA
virus). The program demonstrated the use of Turin university
anti-viral software and the use of Interferon and Vaccine. The
conclusion seemed to be that it is a continuous battle between the
vaccine developers and the hacker virus writers. In such a battle
vaccine writers are at an obvious disadvantage as they strive to
obtain information on, and develop countermeasures for new virus
strains.

Interviews were given with a number of computer "hackers", and
included footage of the Vaxbusters interest group of the Chaos
Computer Club; together with demonstrations of actual breakins to the
computer systems of Singapore Airlines and NASA. The integrity of a
number of commercial bank computer systems was also questioned,
including that of Chase Manhatten.

The program gave a frightening, and emotive portrayal of computer
viruses, trojan horses (including Larry the Lounge Lizard), and the
insecurity of mainframe systems. The program enumerated three possible
courses of action against computer viruses, namely: vaccine
development, change computer and legislation. The conclusion was that
vaccines will become impractical as the threat from, and diversity of
viruses grows. (Since the source of two viruses has now been
published, the threat seems certain to grow).

The inference that legislation is necessary with greater restrictions
on computer access seemed obvious.

Dave Ferbrache                            Personal mail to:
Dept of computer science                  Internet <[e-mail]>
Heriot-Watt University                    Janet    <[e-mail]>
79 Grassmarket                            UUCP     ..!mcvax!hwcs!davidf
Edinburgh,UK. EH1 2HJ                     Tel      (UK) 031-225-6465 ext 553

------------------------------

Date:         Thu, 02 Feb 89 09:23:01 EST
From:         "John P. McNeely" <[e-mail]>
Subject:      Ethical issues.

     Currently there are a wide variety of viruses infecting various
machines across the world. We know the names of the virues and the
damage that they do. But, with the exception of a few viruses and
WORMS, we don't know who the culprits are behind this. What are the
ethics behind writing viruses and WORMS? The controversey still
surrounds Robert Morris jr. and his motives; the Pakistani brothers
wanted to teach people lessons about software piracy. What about the
others? We probably will never know who started what, but we can
ponder the questions as to why a person would want to write a computer
virus or WORM.

Any thoughts on this?

Respond to me either directly or to the list. Thank you.

John P. McNeely

BITNET Address: [e-mail]

------------------------------

Date:     Thu, 02 Feb 89 20:22:22 PST
From:     [e-mail]  (Commander Spock)
Subject:  Gatekeeper Report (Mac)

Although I am *NOT* the author of the program, I would like to post a
notice to those who are currently or will be using Gatekeeper, this
notice may come in handy.  Aside from the notices that the author has
published (from what I can count, currently: 2 posted), I find the
program quite useful in performing searches for various "virus
attacks".  At any rate, I will let you folks (not to mention the
author) know of any problems that I've run acrossed when using
Gatekeeper.  I hope that other users/developers/authors will
reciprocate with their findings.

Current system setup is as follows:

   - Macintosh Plus == 1MB RAM configuration
   - RAM cache OFF
   - 1 Jasmine 100MB hard drive
   - 1 external 800K floppy drive
   - various CDEV's including Gatekeeper
   - Suitecase II Release 1.0.2

Finding:

   1. Have recently upgraded System file to 6.0.3
   2. Have recently upgraded Finder file to 6.1
   3. Have recently upgraded Control Panel to 3.3.1

Observed Problems:

   1. Gatekeeper *DOES NOT* register inside the Control Panel
   2. Miscellaneous error dialogs keep popping up:

      - ID = 02
      - ID = 03
      - ID = 22
      - ID = 15

I realize that the 22 and 15 errors may (or may not) have been
directly or indirectly related to the execution of Gatekeeper within
the Control Panel, provided of course that the close option within the
box (the square) has *NOT* been initiated; otherwise, the resulting
error is an ID = 02.

Could I possibly be doing something wrong?  Second, is there a chance
that I may be able to obtain a copy of the program (source not
necessary) to debug myself (to those who have Gatekeeper 1.0.1)?
Three, any further findings that I find unusual simply by having
Gatekeeper within my System Folder, I will let you folks know.  I feel
that sharing information with those who may be directly or indriectly
affected by the proper executing and dependance of this file is a
must, not a necessity.  I hope that others can feel the same about any
quirks that they may find with this file and others for the Macintosh
and/or IBM.

Should I stand to be corrected (and I have been known to make
mistakes...), please let me know what I might be doing wrong.

With best regards,

Robert S. Radvanovsky          [e-mail]
California Polytechnic Univ.   [e-mail]
Pomona, California

P.S.  I admit, I'M HUMAN!  Kind of a bad position for me, wouldn't you
think?

------------------------------

Date:     Thu, 02 Feb 89 20:43:22 PST
From:     [e-mail]  (Commander Spock)
Subject:  nVIR Assassin... (Mac)

Need some help here.  I have "nVIR Assassin", version 1.0.  I've used
it on various machines and removed copies of "nVIR", supposedly.  What
happened was this: of the 6 applications that were checked, only 2
worked correctly.  The programs checked were:

   - Microsoft Excel 1.05
   - Microsoft Works 2.0
   - Reflex Plus
   - Filemaker 4
   - Font/DA Mover 3.6
   - Hypercard 1.2.1

Of the programs that worked, only Font/DA Mover and and Filemaker 4
worked.  All other programs simply exited to the Finder.  Have I done
something wrong?  I've performed all the necessary steps needed as
outlined by the author.  What happened?

Robert S. Radvanovsky          [e-mail]
California Polytechnic Univ.   [e-mail]
Pomona, California

------------------------------

Date:         Fri, 3 Feb 89 07:58:56 EST
Sender:       Virus Alert List <[e-mail]>
From:         Ken van Wyk <[e-mail]>
Subject:      VIRUS WARNING: Lehigh Virus version II (PC)

A new version of the Lehigh Virus has appeared on our campus; it is
almost identical to the first one, but has a couple of notable
differences.

Yesterday, one of our microcomputer labs reported several students'
disks being destroyed.  We were able to determine that a virus which
appeared identical (at first) to the Lehigh Virus had indeed infected
some of the disks in the public lab.  Disassembly of the virus was
quick and painless because it beared so much resemblance to the
original Lehigh Virus.

The important differences are:

1) "Version II" waits until its generation counter hits 10 before
doing any destruction.

2) II does not store the generation counter on disk, as version I did
in the case of hard disk machines.  That is, a system reboot starts
the generation counter back at 0.

Because of these seemingly minor differences, the virus has a greater
potential for spreading.

Both versions can be referred to as FEVs (Feature Exploiting Viruses)
since they use MS-DOS Interrupt 21H functions for propagating, and
a slightly lower level routine, Interrupt 26H (Absolute Disk Write) to
destroy the boot track of disks (floppy and fixed) once the generation
counter hits 10 (for version II, 4 for version I).

Any/all followups will be posted on VIRUS-L.

Ken van Wyk
Lehigh University Computing Center

[Ed. Editor's apologies for taking so long to get this VIRUS-L digest
together.  The above message should explain why we've been a bit busy
around here...  :-)  With the help of a *very* talented and willing
crew, things seem to be pretty much under control.  Thanks to all!]

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest              Monday, 6 Feb 1989          Volume 2 : Issue 36

Today's Topics:
re: Malicious program classification
Locking out floppy drive boot (PC)
RE: floppy boot (PC)
courses in viruses
re: Hardware lock (PC)
Re: Mac Gatekeeper problems
Virus Attack (PC)
INIT 29 Virus (Mac)
Sneak Virus (Mac)
(c) Brain Virus (PC)

---------------------------------------------------------------------------

Date:        3 February 89, 12:15:38 +0100 (MEZ)
From:        Otto Stolz <[e-mail]>
Subject:     re: Malicious program classification

Hello fellow-huntsmen,

> A kind of "standard notation" [...] in a single sequence of characters.

We should definitely use consistent terminology, but let it not be too
terse.  You should be able to understand a program-description without
referring to some "code-book".

> three kinds of programs - Trojans, worms, and viruses [...]
> CHRISTMA.EXEC would be a fWOR (as far as I know) under this notation.

The term "worm" is widely used (as far as I'm aware) for a program
that spreads over a network without human intervention, using the RJE
services of the network.  (The Internet-worm exploited a bug in the
"fingerd" program, and a backdoor in the "sendmail" program, both
providing unauthorized, RJE-like services.)

CHRISTMA EXEC was definitely not a worm, but something which doesn't
fall within one of Ken H's categories: It was a Trojan horse whose
unexpected action involved sending copies of itself all around the
network; hence, it depended on human intervention, as any virus or
Trojan.  Supposedly, the term "rabbit" I read recently in a survey was
meant to apply to this sort of beast?  (Btw: I'm still waiting,
eagerly, for the results of that survey to be published in VIRUS-L
...)

Hence, we should adopt a more complete terminology for our zoo!

> three methods of activity - hardware, error, and feature exploitation

As to my opinion, this distinction is not so important for
(short-range) virus/worm/&c defeating; it bears more on (long-term)
strategies for systems-architecture developping.  Moreover, most virus
strains do not fall neatly within one of these categories. (Somehow,
the hardware is exploited by every piece of code, isn't it? :-)

Hence, I'd drop this issue for virus catalogues, alerts and the like.

However, Ken H has not mentioned a much more important distinction in
the modes of operation.  If we adopt some formalism, we definitely
should include this one: Link-virus vs. System-Virus.

This distinction only applies to viruses, dividing them into two sub-
categories.
- -- A link virus incorporates itself into application-programs or system
   parts wich are invoked like application-programs (e.g COM, EXE, and
   OVL files in MS-DOS; MODULEs in CMS).  If some virus only incorporates
   itself into application-programs of some particular form, this behavi-
   our should be accounted for in the term (e.g. Blackjack is a COM-virus
   for MS-DOS).
- -- A system virus incorporates itself into a part of the operating system
   that is invoked in some particular way (e.g. a Boot-Sector Virus, a
   COMMAND.COM-Virus, or a KEYB.COM-Virus in MS-DOS).

Maybe, there are similar distinctions to be drawn in other areas, e.g.
for worms.  Opinions?

Btw, a German group around Prof. Klaus Brunnstein at Hamburg is
currently evaluating a sample of various virus strains for Amiga,
MacIntosh, Atari, and MS-DOS systems (about two dozen, altogether) and
of anti-virus soft- ware.  They have started compiling two catalogues
(virus/antivirus) and publishing them on a BB in Germany.  The
distinction between "link" and "system" virus stems from them.  They
also have started translating their catalogue to English.  I suppose,
they are currently checking with Ken [vW, this time], whether it can
be made available on LISTSERV at LEHIIBM.  We'll probably read more of
this endeveaour, shortly.

Good hunting|
              Otto

------------------------------

Date:      Fri, 3 Feb 89 09:49:24 EST
From:      "Bret Ingerman 315-443-1865" <[e-mail]>
Subject:   Locking out floppy drive boot (PC)

   James Ford asks about locking a hard disk to always boot from drive
C: but still have drive A: available.

   It depends on the type of computer.  We have a Zenith AT that can
easily be set up to do this.  By pressing "ALT-CTRL-INS" a
configuration menu pops up.  You can then specify what drive to boot
from.  You can specify always boot from drive A:, always from C:, or
to try A: first and then C:

   Hop this helps.

Bret Ingerman                                 [e-mail]
Syracuse University

------------------------------

Date: Fri, 3 Feb 89 09:50 MST
From: [e-mail]
Subject: RE: floppy boot (PC)

re: computers booting from drive C instead of Drive A: I presume that
you have some sort of IBM PC compatible system.  The boot process is
controlled by the BIOS which is on a ROM chip on the motherboard.  In
older PC's and for example the old COMPAQ portables, the BIOS was not
written to recognize a hard drive.  Thus an upgrade is required.  That
is you need to purchase a new version of the BIOS.  In the old COMPAQ
portables, this costs about $50.  In addition, you may need to replace
the power supply as well

Allen Gordon

------------------------------

Date:  Fri, 3 Feb 89 14:00 EST
From:  Les Gotch <[e-mail]>
Subject:  courses in viruses

In reply to Stan Horowitz's question about COMPUSEC courses at
universities on December 16, 1988:

The Information Security Education Office of the National Security
Agency has worked with members of the academic community and developed
several Computer Security Education Modules.  They were designed for
inclusion in college curricula and range from lower undergraduate
courses through graduate level.  The undergraduate modules can be
incorporated into an existing course structure of a computer science,
engineering, business, or an information science department curricula.

The following Computer Security undergraduate modules are intended to be
used in either a computer science or engineering curricula.  They are
entitled:  Introduction to Information Protection, Database System
Security, Network Security, Formal Specification and Verification,
Operating Systems Security, and Risk Analysis.  These modules are
available for any university or college upon request.

In addition, there are seven Information Security undergraduate modules
designed to stand alone as a course or comprise part of a business or
information science curriculum.  The modules include:  PC/Workstation
Security, Security Fundamentals, Introduction to Information Protection,
Information Security Legislation and Liability, System Security,
Communications Security, and Corporate Security Management.

The University of Maryland's Engineering Department is offering, during
the spring 1989 semester, four computer security graduate courses.
These courses are the first four of nine to be developed that permit a
student to plan a degree program with a concentration in the area of
computer security.  They are entitled:  ENEE 748A Architecture for
Secure Systems, ENEE 748B Networking and Network Security, ENEE 748F
Theoretical Foundations of Computer Security, and ENEE 748G Operating
System Security.

Janet Meeks, [phone]

------------------------------

Date:        3 February 89, 20:11:49 +0100 (MEZ)
From:        Otto Stolz <[e-mail]>
Subject:     re: Hardware lock (PC)

> is there any way to (hardware) fix drive "A" so that the computer will
> ... boot from C always, read/write from A and C ?

We use the "SafeGuard Plus" card for this purpose.
It'll also fix drive B the same way.

We never have experienced any boot-virus :-)

Otto

------------------------------

Date:     Fri,  3 Feb 89 21:37 GMT
From:     Danny Schwendener <[e-mail]>
Subject:  Re: Mac Gatekeeper problems

>Observed Problems:
>   1. Gatekeeper *DOES NOT* register inside the Control Panel

You need to reboot the system first. Apparently, the Gatekeeper
cdev appears only if the INIT has been executed. At least, I
had the same symptoms, which disappeared when I rebooted my
system.

>      - ID = 02
>      - ID = 03
>      - ID = 22
>      - ID = 15

Once you get it to work, Gatekeeper prevents any non-authorised program
from copying resources or/and changing file information. It just
returns an error status code. It's up to the application to perform
a correct error handling.

Unfortunately, many application programmers don't care a bit about
error handling. They don't check if the things have been done as
expected. In some cases, this will cause the application to crash.

Gatekeeper prevents efficiently abuses of the resource manager calls
by any programs (including viruses). Programmers will find it
extremely useful, because you can configure it to give full access of
the resource manager to *some* programs, like compilers. HOWEVER it
takes much more time to have it tuned correctly.

I recommend Gatekeeper to those it was written for, Programmers. Other
people should stick to the Vaccine CDEV.

- -- Danny Schwendener
- -- ETH Macintosh Support, ETH-Zentrum m/s PL, CH-8092 Zuerich
- -- Bitnet :   macman@czheth5a      UUCP   :   {cernvax,mcvax}ethz!macman
- -- Ean    :   [e-mail]   Voice  :   yodel three times

------------------------------

Date:     Fri 03 Feb 1989 17:12 CDT
From:     GREENY <[e-mail]>
Subject:   Virus Attack (PC)

A virus which is purported to be of the BRAIN type has supposedly just
hit EIU (Eastern Illinois University).  Has anyone got any info on how
to eradicate the bugger?  I usually specialize in Mac stuff, but my
school (WIU) and EIU are on the same network so they asked for help
via a local Bulletin Board.

Any info will be appreciated.  Also, I already told them to snag a
copy of NOBRAIN.C from the server...

Bye for now but not for long
Greeny
BITNET: miss026@ecncdc
Internet: [e-mail]
Disclaimer: I only repeat what I hear that ain't classified!

------------------------------

Date:         03 FEB 89 21:12:33 CST
From:     RBCSCG05 <[e-mail]>
Subject:  INIT 29 Virus (Mac)

    This "new" virus (to me at least) seems to be the most dangerous
so far -- attacking even data files !  Gone are the days of restoring
applications only.
    Nevertheless, nothing may be available now to immunize against it
or remove it, but I think it can be "easierly" detected then through
RESEDIT and the like (especially since that is a dangerous application
to pry through your disk and programs, even knowing what you are
doing).  Yes, I may be overly cautious, but you can never be when it
comes to viruses.
    A program called VCHECK creates checksums of your applications and
creates a corresponding report with can be easily printed.  After the
first checksums are done, subsequent ones will use the previous one to
see if anything has changed -- this includes if the applications may
have been moved, renamed or duplicated.  You will be shown those that
may have changed.
   VCHECK by Albert Lunde at Northwestern University.  The version I
have is 1.3 (7/5/1988).  I believe it is available at the VIRUS-L
archive on the network BITNET.  I do not remember where I got my
from, but I know it was off the BITNET network.  After a SCORES
virus hit me, I searched for any and all anti-viral software.
   If you use a checksum method, keep the checksum document on a
separate disk so it will not be possibly corrupted (viruses or
otherwise).


Chris Osterheld  <[e-mail]>

------------------------------

Date:         Fri, 03 Feb 89 19:27:29 PST
From:         Sam Cropsey <[e-mail]>
Subject:      Sneak Virus (Mac)

Has anyone dealt with the sneak virus?  Well we have it and I sure do
not want it.  If anyone has some info...please send it to me at:

SAM@POMONA      or     SCROPSEY@PCMATH.  Thanks...

------------------------------

Date:    Fri, 03 Feb 89 19:34:31 PST
From:    "Sam Cropsey (Micro Coord. Pomona College)" <[e-mail]>
Subject: (c) Brain Virus (PC)

I know much has been written concerning the Brain virus on PC's.
However, I do not get the chance to read all that is published on this
service.  If anyone has some useful info on combatting the Brain, I
would greatly appreciate the help.  My address is
SAM@POMONA OR SCROPSEY@PCMATH.  Thanks for your help...

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest              Monday, 6 Feb 1989          Volume 2 : Issue 37

Today's Topics:
Not So Sneaky, Maybe (Mac)
How-to-Infect Book
Master virus listing

---------------------------------------------------------------------------

Date:         Mon, 06 Feb 89 10:13:59 EST
From:         Joe McMahon <[e-mail]>
Subject:      Not So Sneaky, Maybe (Mac)

>From:         Sam Cropsey <[e-mail]>
>Subject:      Sneak Virus (Mac)
>
>Has anyone dealt with the sneak virus?  Well we have it and I sure do
>not want it.  If anyone has some info...please send it to me at:
>
>SAM@POMONA      or     SCROPSEY@PCMATH.  Thanks...

What version of Interferon are you using, and in what application did
you find a "Sneak" virus? You have a couple of possibilites here. One,
you really do have a virus, but Interferon is too old to know it (Hpat
or INIT 29). Two, you have System 6.0.2 and an Interferon previous to
3.0 (that will show the new LaserPrep and LaserWriter drivers as in-
fected), or you have TOPS (whose internal structure LOOKS like a Sneak
virus, but isn't).

- --- Joe M.

------------------------------

Date:         Mon, 06 Feb 89 11:04:42 ECT
From:         Art Weisenseel <[e-mail]>
Subject:      How-to-Infect Book

     In Bill Machrone's column in the latest PC Magazine (Feb. 28,
1989) he mentions that he has seen a book which shows interested
parties not how to protect oneself against viruses and the like, but
how to WRITE the suckers.  The author has thoughtfully provided
listings in 370 Assembler, EXEC (the Christmas EXEC!), PC Assembler,
Pascal, BASIC, etc. etc.. Monitor and floppy drive destroying tips
also seem to be included, as well as advice on how to hide your
handiwork.  Machrone has not offered the title or the author's name,
but if the book really exists and if its techniques really work I'm
sure we will hear a lot more of it real soon now.

Great.  An "Anarchist's Cookbook" for computers.  I think the concept
is pretty reprehensible.

Art Weisenseel
[e-mail]
Computer Services
State University of New York - College at Purchase
"Twenty Seconds Ahead of the Past"

------------------------------

Date: Mon, 6 Feb 89 15:56 EST
From: <[e-mail]>
Subject: Master virus listing

     As a somewhat new member of this list, I was wondering if anyone
has compiled a list of major viruses, and their symptoms.  Also, if
such a list already exists, where would I find it?  It would make
these messages much easier to understand....

                                                       Paul Bienvenue

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest              Tuesday, 7 Feb 1989         Volume 2 : Issue 38

Today's Topics:
Re: How-to-Infect Book
Re: new Anarchist's Cookbook
VirusDetective's configurability (Mac)

---------------------------------------------------------------------------

Date:         Mon, 06 Feb 89 16:19:58 CST
From:         Rob Caton <[e-mail]>
Subject:      Re: How-to-Infect Book

>     In Bill Machrone's column in the latest PC Magazine (Feb. 28,
>1989) he mentions that he has seen a book which shows interested
>parties not how to protect oneself against viruses and the like, but
>how to WRITE the suckers.  The author has thoughtfully provided
...(Stuff deleted)...
>Great.  An "Anarchist's Cookbook" for computers.  I think the concept
>is pretty reprehensible.

I wouldn't be surprised if it does exist.  I have seen a book called
"The Computer Underground" which gives tips and techniques for
breaking into computer systems, phreaking, blue boxing, etc.  I'm just
surprised that a book on writing viruses hasn't been released earlier.

>Art Weisenseel
>[e-mail]

Robert Caton
C70301RC@WUVMD
Washington University

------------------------------

Date:         Mon, 06 Feb 89 19:25:04 EST
From:         "Jeffery K. Bacon" <[e-mail]>
Subject:      Re: new Anarchist's Cookbook

     I personally found the Anarchist's Cookbook to be an awfully
enlightening and useful book, if only because it taught me things I
didn't know and might need someday. (Yeah, I read it. Couldn't find a
copy to buy for myself tho.)  It also taught me what I might want to
look out for.

     I don't think the parallel is quite accurate. I can think of
cases where I could use what I learned from the Cookbook. Why would
anyone ever NEED to write a virus/worm/trojan?

     In any case, I'm afraid something like this was bound to happen
eventually anyway. It's a free-information society, and virus-writing
tricks are as much information as anything else. Besides, it might
sell. I for one would be most interested in seeing such a book, esp
since it would help me to understand what these people are doing in
the first place. (The smallest computer I know anything useful about
is an IBM PC-RT; my normal working habitat is 370 VM/CMS and SunOS. My
knowledge of PCs extends to writing very simple batch files, and all I
know about a Mac is 'point-and-click-and-pray', so I tend to get left
in the dust sometimes.)

     Just as a matter of debate, do (the collectve you) think that
such a book would be that harmful? If someone was really intent on
writing a virus, it seems that they would find out what they need to
know anyway, somehow. Sure, there would be a few who would
'dabble-and-poke' at it because of the book, but they probably
wouldn't be able to do anything much. ??? (Point-of-debate only; I
tend to think some other things.)

     -JB

------------------------------

Date:     Tue,  7 Feb 89 13:12 GMT
From:     Danny Schwendener <[e-mail]>
Subject:  VirusDetective's configurability (Mac)

Today a user came by and told me he found the "INIT 10" virus. When I
asked what virus he was talking about, he replied "I don't know.  But
someone on [network name deleted] recommended to add INIT 6,10 17 and
32 to the Search list in VirusDetective". As I expected, the user had
found a legal INIT 10 resource in a CDEV (Vaccine), and thought it was
a virus.

Those of you who follow the virus discussions will probably know that
the Scores virus creates *among other resources* three INIT resources
of ID 6, 10 and 17, and that the nVIR virus writes 6 nVIR resources as
well as one INIT 32 resource into the System. But finding a single
INIT 10 without any other symptoms does not necessarily mean that
you're infected, even if that INIT is in the System file.

To detect Scores, Virus Detective's Author Jeffrey Shulman has
included the search string "CODE Jstart 7026 - for finding Scores in
applications".  If you want to search for Scores in the System file,
too, include the search string "DATA Dual -4001 7026 - for finding
Scores in System".  But don't look for a plain INIT 6 or 10 or 17, as
there are plenty of them in the sane world.

Don't abuse the configurability of Programs such as VirusDetective.
Adding strings like "INIT ID 6" or "INIT ID 32" will not increase the
program's success rate. Au contraire. All it will change is that
you'll have VirusDetective ringing bells and whistling like crazy on
many uninfected CDEVs and INITs.

Following are the Search strings that are included in VirusDetective
2.0 (plus one that finds Scores in the System). They are sufficient to
detect the nVIR, Hpat, Scores and INIT29 viruses on your disks.

nVIR any - For finding nVIR in all files
Hpat any - For finding nVIR in all files
INIT Dual 29 712 - For finding INIT29 in non-application files
CODE Jstart 712 - For finding INIT29 in applications
CODE Jstart 7026 - For finding Scores in applications
DATA Dual -4001 7026 - For finding Scores in System,Desktop,Scores
     files (*)

(*) Note that if VD rings on this, the two System files "Note Pad
    File" and "Scrapbook File" will be infected, too, and should be
    removed.

- -- Danny Schwendener
   ETH Macintosh Support, ETH-Zentrum, CH-8092 Zuerich, Switzerland
   Bitnet:   macman@czheth5a      UUCP:  cernvax!ethz!macman
   InterNet: [e-mail]   Voice: yodel three times

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest             Wednesday, 8 Feb 1989        Volume 2 : Issue 39

Today's Topics:
On COMMAND.COM viruses... (PC)
Re: Master Virus Listing info request
Virus Manual/Computer Phreak's Cookbook/Bit Jammer's Bible
(c) Brain (PC)
Re: Anarchist Cookbook for Computers
How To Book, 2
New Macintosh Virus (from Newsgroups: comp.sys.mac)
Latent Mac viruses??

---------------------------------------------------------------------------

Date: Tue, 7 Feb 89 10:36:40 est
From: ubu![e-mail]
Subject: On COMMAND.COM viruses... (PC)

This latest occurrence of the Lehigh Virus made me realize (again) how
blatantly hole ridden the COMMAND.COM file is.  The last couple
hundred bytes in every version of COMMAND.COM (that I've seen) contain
all 00s (for stack space while the program is executing).  Also, the
*very first* instruction in the file is a JMP.  What's worse, almost
all PCs have a COMMAND.COM file in their root directory.  It doesn't
take a rocket scientist to figure out how to exploit these
similarities.

The best thing that a person can do (imho) to protect themselves from
a "garden variety COMMAND.COM virus" is to remove their computer(s)
from this homogeneous environment by placing a statement like:

SHELL=C:\BIN\DOS\COMMAND.COM /P

in each CONFIG.SYS file, thus booting from a COMMAND.COM in a
different directory, would help.  Also, put a:

SET COMSPEC=C:\BIN\DOS\COMMAND.COM

in each AUTOEXEC.BAT file.  This will allow normal functioning in
MS-DOS without leaving a COMMAND.COM file wide open to viruses.  Once
exception to this (at least in the case of Zenith MS-DOS) is with the
FORMAT command; it requires a COMMAND.COM file in the root directory
to format a bootable disk.  That is, the authors of FORMAT (Microsoft?
Zenith?) didn't adhere to the standard way of pointing to the
COMMAND.COM (heavy sigh)...

I realize that this has all been discussed before on VIRUS-L, and that
it certainly isn't going to stop all viruses (!).  It will, however,
at least hide a major Achilles Tendon in MS-DOS.  Of course, if
*everyone* did the above, then the environment would once again become
homogeneous, so each person should find a different "hiding place" for
their COMMAND.COM file.

Also, the best solution would be for Microsoft to change some of their
programming practices.  Static memory allocation is asking for
problems.  It's also surprising how many programs place a JMP
statement as their very first instruction.

For what it's worth,

Ken

------------------------------

Date:    7 Feb 89
From:    J. D. Abolins <[e-mail]>
Subject: Re: Master Virus Listing info request

For Paul Bienevue's question about a master virus listing, I don't
of a comprehensive existing one yet. There are several of us who
are attempting to get a list going.

The DIRTY DOZEN listing by Eric Newhouse has a virus section. It is
the only widely available attempted virus listing I know of. But the
listing is woefully out of date (although for other malicious programs
it is excellent.) In communicating with Eric again on the Crest BBS,
he told that he plans one more Dirty Dozen listing- version 9.0. After
that, he might be "retiring" from makingmore such listings. In any
case, we (the people working on a virus listing) aim to continue the
virus listing past the Dirty Dozen if it should cease.

A general question: What are some of the taxonomical conventions for
virus cases? Ie; naming schemes for the cases.Some have been discussed
here lately. Of course, there is the approach of naming the case after
it first major reported site (eg; Lehigh virus, Jerusalem virus, etc.)
But such conventions can create problems, including giving the im-
pression that the case is localized and by causing adverse publicity
for the site named.I would like to have the choices of conventions
so that a "neutral" scheme could be used for virus listing. The
other names could given as "aliases, AKA's)

Thank you.
J.D. Abolins / 301 N. Harrison Str. #197 / Princeton, NJ 08540 USA
[phone]

------------------------------

Date:         Tue, 07 Feb 89 11:37:08 EDT
From:         [e-mail]
Subject:      Virus Manual/Computer Phreak's Cookbook/Bit Jammer's Bible

We would like very much to capture a copy of this publication.
(Please, no flaming diatribes about the evils of reading such
material.) We now have fairly good evidence that it is already in
circulation at at least one institution with which we have close ties
and with whom we share a certain common body of studetns. The
potential result of that is not hard to assess. Additionally, this
list itself has already offered an awareness of such a publication to
the student community.

We need to be aware of what we could be up against.

Please reply to me privately, for obvious reasons.

............................................................................
|W. K. "Bill" Gorman                 "Do             Foust Hall # 5        |
|PROFS System Administrator        SOMETHING,        Computer Services     |
|Central Michigan University      even if it's       Mt. Pleasant, MI 48858|
|[e-mail]                wrong!"         [phone]        |
|Disclaimer: These opinions are guaranteed against defects in materials and|
|workmanship for a period not to exceed transmission time.                 |
|..........................................................................|

------------------------------

Date:         Tue, 7 Feb 1989 09:41 PAC
From:         Marty Zimmerman <[e-mail]>
Subject:      (c) Brain (PC)

I'm looking for any information or advice on the "(c) Brain" virus.
Has anyone documented the means by which this thing breeds?  Thanks in
advance for your help.

P.S. - please reply directly to me, unless you think your comments
would be of interest to everyone.

Marty Zimmerman
University of Idaho
Computer Services
<[e-mail]>

[Ed. Take a look at J.D. Abolins's message in this digest.]

------------------------------

Date:         Tue, 7 Feb 1989 12:38 EST
From:         Bruce Ide <[e-mail]>
Subject:      Re: Anarchist Cookbook for Computers

     If they tell you how to write 'em, the are also telling you what
to look out for and how to destroy them. I'd buy the book.
                                      -Grey Fox

------------------------------

Date:         Tue, 07 Feb 89 19:12:53 MEZ
From:         Konrad Neuwirth <[e-mail]>
Subject:      How To Book, 2

I just wanted my $0.02 to the discussion about a HOW TO book. I don't
think it is a bad idea to publish a virus. If someone types in the
virus from the book I cited earlier, almost nothing happens. and if he
just changes the routines which do something to the system (the writer
uses a "SHELL") it should be easier to write a antidote.  I know it is
not easy to find about how the code was originally written, but it
should be easier to scan a program or anything infectable for a
certain bit of code, which can come from the book.

- -konrad

p.s.: the book doesn't give a listing of an antidote. maybe that would
be an idea worth thinking about...

------------------------------

Date: 7 Feb 89 15:29:46 GMT
From: [e-mail] (Robert J. Hammen)
Subject: New Macintosh Virus (from Newsgroups: comp.sys.mac)

This is some info on a new Mac virus. This article was originally
posted on CompuServe, and reposted on Delphi by Robert Wiggins:

Reposted message at the request of the author, Thierry DeLettre: Until
now, all known Macintosh viruses could be easily detected by the
additional resources they created. Now, it's over... There is at least
one virus that creates no additionnal resource. This virus is called
ANTI, and infects only applications (and other files, ID=1 resource.
It inserts a JSR at the beginning of the resource and all the virus
code at the end. It seems to be very recent, but we have already found
infected Macintoshes in Paris and Marseilles, and it is probably
making its way fast across all Europe. This virus is _not_ detected by
VirusDetective or other utilities. It installs itself even when
Vaccine is on. Vaccine beeps only if the 'Always compile MPW Inits' is
_not_ checked. Virus Rx does not detect ANTI's presence in other
files, but, when infected itself, changes its name to 'Throw me in the
trash'. It doesn't seem to infect all applications, but only some (the
ones with a CODE 1 resource called 'Main'). We haven't found how it
works yet.  It doesn't seem to change the System file, which doesn't
contain a CODE resource. The contagion seems to be spread by the
Finder. To see if an application is infected, you have to open its
CODE ID=1 resource with ResEdit and search for the ASCII string
'ANTI'. You can also use the advanced features (resource fork search)
of GOfer. We haven't yet found the way to remove it, but only a way to
deactivate it by changing the first words of the virus code to a RTS.
There is a strange story about this virus. Two years ago, Apple
France's developper's support manager, Alain Andrieux, wrote a utility
for his own use called 'Stamp', with which he marked the programs he
gave to developpers. If a confidential program was given out, he could
easily know where it came from. His program added a CODE resource to
the marked files, but did _not_ change anything in the CODE 1
resource. In January 89, a 'new' version of this program (Stamp 1.0b5)
began to spread in the French Mac community. When run, this program
installs the 'ANTI' virus into the marked or checked applications
and/or into the Finder. These infected applications and Finders then
become contagious themselves. It seems the virus author stole the
source code of this program, changed it into a virus installer, then
gave it away. Obviously, inserting a virus installer in an Apple
program was done to damage Apple France's reputation...
Thierry D,
Chief Mac Sysop,
Calvacom .

P.S. A copy of the virus has been sent to Jeffrey Shulman and Robert
Woodhead, so that they can update their anti-viruses consequently. .

P.P.S. I don't have access to other major American on-line services,
so please upload the above information where you can. Thierry can be
reached via CompuServe at 76670,2260.

///////////////////////////////////////////////////////////////////////////
/ Robert Hammen  | [e-mail] | uwmcsd1!uwmcsd4!hammen     /
/ Delphi: HAMMEN | GEnie: R.Hammen | CI$: 70701,2104 | MacNet: HAMMEN     /
/ Bulfin Printers | 1887 N. Water | Milwaukee WI 53202 | [phone]   /
/ 3839 N. Humboldt #204 | Milwaukee WI 53212 | [phone] (h)         /
///////////////////////////////////////////////////////////////////////////

------------------------------

Date: Tue,  7 Feb 89 17:04:31 -0500 (EST)
From: Mark Thormann <[e-mail]>
Subject: Latent Mac viruses??

Hi.  I was wondering if anyone had heard of any latent versions of
nVir, Scores, etc. which waited until a certain number of copies had
been made or a certain date passed before appearing.  Would one of the
current virus detectors spot one of these things before it activated?
Any specific experiences anyone has had like this?  If you reply to
this mailing list, please carbon copy to me.

Thanks,

 Mark Thormann
 Carnegie Mellon U.

ARPANET: [e-mail]

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest             Wednesday, 8 Feb 1989        Volume 2 : Issue 40

Today's Topics:
Re: Info on How To Book
Dormant Viruses (Mac & general)
Virus susceptability (Mac)
Re: CTRL-ALT-INS rebooting (PC)
Virus Technical Report

---------------------------------------------------------------------------

Date:         Wed, 08 Feb 89 15:42:01 MEZ
From:         Konrad Neuwirth <[e-mail]>
Subject:      Re: Info on How To Book

I know a german book called "Das Grosse Computervirenbuch" by a guy
called Ralf Burger and published in germany by Data Becker.  The people
responsible for bringing the Data Becker things to America are Abacus
Software. I don't have the address handy but can send it to you if you
want. I just got to look for it....

- -Konrad

[Ed. Thanks for the info.  I trust that the version in America has
been translated?  I suppose that it's arguably a good idea to send
information like this over the nets, but I feel that once a book like
this has been published, any damage is already done.  I think that it
is certainly worth _our_ while to read books/publications/etc. like
this for our own protection, if nothing else.  Suggestions?]

------------------------------

Date:         Wed, 08 Feb 89 13:15:54 EST
From:         Joe McMahon <[e-mail]>
Subject:      Dormant Viruses (Mac & general)

The Scores/nVIR/Hpat/INIT 29 viruses can all be found, whether or not
there is dormancy code in them, because the resources which define the
viruses are detectable.

This is what's so bad about the new ANTI virus; that sucker just
munges itself into your code -- no detectable resources, no virus
(from the current detectors).

- --- Joe M.

------------------------------

Date:         Wed, 8 Feb 1989 14:13 EST
From:         Bruce Ide <[e-mail]>
Subject:      Virus susceptability (Mac)

     Just by reading through this discussion, I see that the Apple Mac
seems to be struck more by viruses than any other computer. Is this
true, or do we just have a lot of Mac users here? Also, what makes the
Mac environment so succeptable to these viruses?

                                     -Grey Fox

------------------------------

Date:         Wed, 08 Feb 89 14:35:38 EST
From:         Neil Goldman <[e-mail]>
Subject:      Re: CTRL-ALT-INS rebooting (PC)

Brent Ingerman responds to a question about *physically* preventing
the computer to boot from the A drive.  Zenith PC's have a 'setup'
screen which is accessed via CTRL-ALT-INS.  One of the options is to
specify the drive from which to boot.

Problems: 1. Any user having knowledge of the 'setup' screen could reset
             the boot drive to A.

          2. Any user NOT having knowledge of the 'setup' screen could
             (and most likely would) find it 'by accident' when s/he,
             intending to press CTRL-ALT-DEL, presses CTRL-ALT-INS.

          3. This fix is software-based.  So here we return to the
             system-specific virus controversy, which I will not rehash here.

I do not have the technical expertise to answer the *original*
question of a *hardware* modification which would prevent booting from
drive A.

Any ideas?

- --------------------------------------------------------------------
Neil A. Goldman                        [e-mail]

Replies, Concerns, Disagreements, and Flames expected.
Mastercard, Visa, and American Express not accepted.
Acknowledge-To: <NG44SPEL@MIAMIU>

------------------------------

Date:       Wed, 8 Feb 89 19:03:34 GMT
From:       David.J.Ferbrache <[e-mail]>
Subject:    Virus Technical Report

       -------------------------------------------------------------
       A review of the threat posed to the security and integrity of
       microcomputer systems posed by self-replicating code segments
       -------------------------------------------------------------

I am in the process of compiling information on existing computer
viruses, with a view to the production of a technical paper reviewing
the threat to system security posed by both present computer viruses
and likely future developments.

To this end I would be very grateful for information on individual
infections, preferably detailing the symptoms observed, damage caused
and disinfection techniques applied. Naturally I am also interested in
details of the operation of the viruses, although I appreciate the
reticence shown by infected parties to disseminate any details of
virus operation, on the basis that it could lead to development of
further viruses.

The technical report is part of a Doctoral research thesis in computer
security, and will be available in late May. Distribution of the
technical report will be restricted to people who have a legitimate
interest (ie systems managers, commercial concerns, research), as I
expect to review the techniques exploited by viruses in a fair degree
of detail at the BIOS/DOS interface level. The report will consider
the techniques used by virus to duplicate, the ways in which viruses
gain control of the computer system, the camouflage techniques adopted
and a brief overview of the existing computer viruses. Finally the
report will consider the likely development of the threat from
viruses, and how this developing threat can be addressed by protective
software in both virtual and non-virtual machine operating
environments.

At the moment I know of the following viruses:

IBM PC MS/DOS
1. Lehigh variant 1 and 2              2. New Zealand (stoned)
3. Vienna (Austrian, 648)              4. Blackjack (1701, 1704)
5. Italian (Ping Pong)                 6. Israeli variant 1 (Friday 13th, 1813,
                                          PLO, Jerusalem), variant 2, variant 3
                                          (April 1st), variant 4
7. Brain (Pakastani) and variants      8. Yale

Also potentially variant of the Rush Hour and VirDem viruses developed
during the CCC's work on viruses.

APPLE MAC
1. NVir variant A and B, Hpat           2. Scores
3. INIT 29                              4. ANTI
5. Peace (MacMag)

APPLE II
1. Elk

AMIGA
1. SCA                                  2. Byte Bandit
3. IRQ

ATARI ST
1. Boot sector                          2. Virus construction set viruses

Mainframe OS worms
1. Internet worm                        2. DECNET worm
2. BITNET Xmas chain letter

I would be grateful for any information on these, or any other
viruses.  Reports of infection may be given in confidence, in which
case they will only be used as an indication of geographical
distribution of infection.

A summary of known viruses, their symptoms, geographic distribution
and known disinfection measures will be posted to the list as soon as
sufficient information is available to prepare an interim report.

As part of the paper I will also be reviewing the effectiveness of
viral disinfection software, and would thus be interested in details
of any software you use, its effectiveness, and availability.

Thanks for your time!

For those interested here is a summary of a few of the virus reports
published on virus-l and usenet,

   Subject, author and date                     Virus      Virus-l issue

   THE AMIGA VIRUS - Bill Koester (CATS)        SCA        LOG8805
       comp.sys.amiga, 13 November 1987

   New Year's Virus Report - George Robbins     IRQ
       1 January 1989, comp.sys.amiga

   The Elk Cloner V2.0 - Phil Goetz             ELK
       26 Apr 1988

   THE ATARI ST VIRUS - Chris Allen             ATARI ST
       22 March 1988, comp.sys.atari

   Features of Blackjack Virus, Otto Stolz      BLACKJACK  v2.24
       24 Jan 1989

   Comments on the "(c) Brain" Virus            BRAIN      LOG8805
       Joseph Sieczkowski, Apr 1988

   Brain and the boot sequence, Dimitri Vulis   BRAIN      v2.5
        5 Jan 1989

   The Israeli viruses, Y.Radai                 ISRAELI    LOG8805
       2 May 1988

   VIRUS WARNING: Lehigh virus version II       LEHIGH v2  v2.35
       Ken van Wyk, 3 Feb 1989

   The Ping-Pong virus, Y.Radai                 ITALIAN    v2.18
       17 Jan 1989

   Known PC Viruses in the UK and their effects MOST PC    v2.23
       Alan Solomon, 1989

   Yale Virus Info, Chris Bracy,                YALE       LOG8809a
       2 Sep 1988

   New Macintosh Virus, Robert Hammen           ANTI
       comp.sys.mac, 7 Feb 1989

   Hpat virus-it is a slightly modified nVIR    HPAT
       Alexis Rosen, comp.sys.mac, 7 Jan 1989

   INIT 29: a brief description,                INIT 29    v2.18
       Joel Levin, 18 Jan 1989

   A detailed description of the INIT 29 virus  INIT 29    v2.30
       Thomas Bond, 27 Jan 1989

   The Scores Virus, John Norstad               SCORES     LOG8804
       info-mac digest, 23 Apr 1988

   Macintosh infection at Seale-Hayne College   TSUNAMI    LOG8808d
       Adrian Vranch, 8 July 1988

   DEFENCE DATA NETWORK MANAGEMENT BULLETIN,    DECNET     (see also v1.59a)
       50, 23 Dec 1988,

   The internet worm program, an analysis       INTERNET
       Gene Spafford, Nov 1988

I apologise for any researchers whose articles I have not cited, in
what is currently an incomplete list of references. Hopefully, this
article will be of some use in providing a general list of viruses
which have affected computer systems in the past.

Thanks for your time, and I look forward to any information you can
supply me with.

Dave Ferbrache                            Personal mail to:
Dept of computer science                  Internet <[e-mail]>
Heriot-Watt University                    Janet    <[e-mail]>
79 Grassmarket                            UUCP     ..!mcvax!hwcs!davidf
Edinburgh,UK. EH1 2HJ                     Tel      (UK) 031-225-6465 ext 553

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest             Thursday, 9 Feb 1989         Volume 2 : Issue 41

Today's Topics:
Arpa Worm & Knowledge spread
Request for info on a message given by Interferon 3.0 (Mac)
Re: Virus Technical Report (Apple // query)
A virus book
Macintosh ANTI virus (from VALERT-L)

---------------------------------------------------------------------------

Date:         Wed, 8 Feb 1989 18:11 EST
From:         Bruce Ide <[e-mail]>
Subject:      Arpa Worm & Knowledge spread

     I hate to tell you guys, but the info provided in most newspapers
after that nasty ARPA worm hit was enough for me and the consultants
here to go on if we happened to write another one. Don't complain
about these books when Magazines have been supplying this info for
years. I read the Articles in Science Digest and said "Hey, I could do
that." Not that I ever did, but the concepts are fairly easy, at least
for worms and trojans. Any good programmer could whip up something
like the Bitnet XMAS greeting in thirty minutes. But not too many
would because we are not all wierdoes who enjoy that sort of thing.
This book won't really make much difference in what's out there. There
won't be many new viruses, but maybe more old ones, if listings are
provided in the book. Thought you'd like to know...
                                     -Grey Fox

------------------------------

Date:     Wed,  8 Feb 89 19:17 EST
From:     Cincinnati Bengals. <[e-mail]>
Subject:  Request for info on a message given by Interferon 3.0 (Mac)

     Recently we've gotten a copy of Interferon 3.0 for our Mac's here
at Xavier to eradicate the nVIR virus that infected our hard disks.
Occasionally, when a disk is checked, the message, "This is not an HPS
disk" appears.  Does anyone know what this means?

Thanks,

Tom Kummer

Acknowledge to: [e-mail]

------------------------------

Date:    Wed, 08 Feb 89  21:30:02 EST
From:    "Bruce Howells" <[e-mail]>
Subject: Re: Virus Technical Report (Apple // query)

In 2.40, David J. Ferbrache mentions an Apple // virus (elk).  This is
the first time I've seen reference to this critter - any info out
there other than it's name??

Bruce Howells, [e-mail] / [e-mail]

------------------------------

Date:     Wed,  8 Feb 89 22:59 EST
From:     Dimitri Vulis <[e-mail]>
Subject:  A virus book

Ralf Burger
Computer Viruses: a High Tech Disease
Abacus, Inc
5370 52nd Street Southeast
Grand Rapid, Michigan 49508
282 pp.

But is this THE book Bill Machrone wrote about?

------------------------------

Date:         Wed, 8 Feb 89 10:43:00 CST
Sender:       Virus Alert List <[e-mail]>
From:         "David Richardson, UT-Arlington" <[e-mail]>
Subject:      Macintosh ANTI virus (from VALERT-L)

NEW MAC VIRUS:             NAME:  ANTI,
- ----------------------------------------------------
SUMMARY:

Description: similar to nVIR, SCORES, & others, but does NOT add new
resources, only changes existing ones.

Detection: Vaccine beeps ONLY when "always compile MPW inits" is
unchecked.  Cannot be detected by virus-detective or most other
antiviral utilities.

Symptoms for novice:  ??

[...forwarded text deleted - can be found in VIRUS-L Volume 2 Issue 39...]

- -David Richardson, The University of Texas at Arlington
Bitnet: b645zax@utarlg   Internet/Domain:  [e-mail]
UUCP: ...!{ames,sun,texbell,uunet}!utarlg.arl.utexas.edu!b645zax
USnailMail: P O Box 192053, Arlington, TX  76019-2053
PhoNet: 817-273-3656 (FREE from Dallas/Ft. Worth, school months only)

PS:  I (David Richardson) have never actually seen this, & I honestly hope
it is a hoax (like the "modem  virus"), but it is too scary to ignore.

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest             Thursday, 9 Feb 1989         Volume 2 : Issue 42

Today's Topics:
Re: How to book
On virus education
Finding ANTI (Mac)
Interferon Question (Mac)
The BOOK
Information Request
RE: Request for info... Interferon 3.0 (Mac)
Protecting Public IBM PC's

---------------------------------------------------------------------------

Date: Thu, 9 Feb 89 08:17:06 est
From: [e-mail]
Subject: Re: How to book

     I think the book Konrad Neuwirth was talking about is Computer
Viruses: A High-Tech Disease by R. Burger.  It was translated from
German (and is in English) and published by Abacus.  The address for
Abacus is: 5370 52nd Street, SE / Grand Rapids, Mi 49508.
     In the book, there are small programs for the PC that are written
in assembly language, basic, and Pascal that are examples to show how
different viruses work.  There are examples of batch viruses and in
the case of the network virus - Christmas.exec, the Christmas virus.
He tries to explain in some cases how these work and even suggests the
shell if this is for demonstration purposes.  There is also a
statement in the front of the book that states that the programs are
for testing and demonstration programs only.  Also there is a
demonstration program on how the virus works.
     Hopefully this message is just descriptive.  I didn't mean to
have any public opinions on this book.  I was just trying to give you
an idea of what is in it, not the quality.

                   Pat Reedy
                   [e-mail]

------------------------------

Date:     Wed, 8 Feb 89 20:15 EST
From:     <[e-mail]>
Subject:  On virus education

Although I have no idea of when the first "virus" ever came on the
scene, I have noticed that the rage of epidemics has increased
steadily with the growing spirit of "sharing," at least in the PC
community.  I remember the days of logging onto bulletin boards and
not really having to worry about trying someone's new, improved,
handy-dandy program that prided doing everything but walking the dog.
It's really a shame that just when we're at the brink of a great trend
like this that people (like Mr. Morris) have to take advantage it.

My my outburst is partly a comment on Art Weisenseel's message on the
"Anarchist's Cookbook" for computers (n2v37), and partly a comment on
Robert Radvanovsky's message on corporate intentional viruses.
However, might I suggest something similar to what our Surgeon General
has said about AIDS: Educate the people!!!  If we can get it across to
students in the colleges (high schools?) and to some people in the
workplace that these "Malicious Pieces of Code" destroy an open
atmosphere for software development on all levels and also waste of
alot of precious time and money (I've seen the setup at Lehigh and
everyone there works tremendously hard to prevent/control virus
outbreaks) then maybe, just maybe, we could all get our work done
without having to have twelve backups, two of which are locked away in
a safety-deposit box somewhere.

"There's a dark side to every powerful technology..."
Michael Hawley, Programmers at work.

        Bob Rudis
        BITNET: RER1@SCRANTON

------------------------------

Date:         Thu, 09 Feb 89 10:10:32 EST
From:         Joe McMahon <[e-mail]>
Subject:      Finding ANTI (Mac)

The new ANTI virus works much like a PC virus, causing CODE segment 1
of applications to grow by a certain amount.

If you've been using a checksumming program, you should be able to
detect ANTI by running a checksumming sweep (the VCheck program will
do this).

Also, GoFer (sp?) can check the resource forks of files for the string
"ANTI" (which is where the virus's name comes from). FEdit can also be
used for this.

Jeff Shulman (the author of VirusDetective (tm)) is planning on adding
code to it to be able to scan for arbitrary hex sequences in a file.

Also, it has been sent on to Bob Woodhead, who will be working on
adding it to Virex.

More as it develops...

 --- Joe M.

------------------------------

Date:         Thu, 09 Feb 89 10:15:37 EST
From:         Joe McMahon <[e-mail]>
Subject:      Interferon Question (Mac)

The message you are getting reads, I think, "This is not an _HFS_
disk."  The disk you are trying to check is an old 400K MFS-formatted
disk, which uses the OLD Mac file system from before System 3.0.

Interferon cannot check these disks. I don't use 400K disks now. Have
you tried Virus Rx against those? Also, you might want to copy those
to an 800K disk and then check them.

 --- Joe M.

------------------------------

Date:     Thu,  9 Feb 89 10:44 EST
From:     <[e-mail]>
Subject:  The BOOK

        I talked to Bill Machrone, PC MAG columnist, a few days ago.
He confirmed for me that the book he alluded to was indeed "Computer Viruses-
A High Tech Disease", by Ralf Burger, American (English language) publisher,
Abacus, 5370 52nd Street SE, Grand Rapids, MI 49508, ISBN #1-55755-043-3,
Copyright 1988. Originally published in German by Data Becker, GmbH,
Merowingerstrase 30, 4000 Dusseldorf, West Germany.  The phone number for
Abacus is 1-800-451-4319.
        The book is good.  The viruses, worms, etc do work.  We have tried
them.  What do you think of the ethics of asking our librarian to remove
it from general circulation?

Steve Rogowski
Computing Center
SUNY-Albany
518-442-3767

------------------------------

Date:         Thu, 9 Feb 89 13:06:58 EST
From:         ca126 <[e-mail]>
Subject:      Information Request

        I am a second year computer science student at the City
University, London, England. As part of my degree course I am writing
a project on UNIX security with three fellow students. I have received
a report on the internet worm, written by Bob Page, and wondered if
you could send me more information on viruses/worms found on various
networks, their (apparent) purpose and the methods used to prevent
their spread.
        I would be grateful if you could also send me Bob Page's email
address, as it was not included in the report, and I have been unable
to contact him as yet.

                        Thanking you in anticipation,

                        Adrian Jones.   [e-mail]

                also    David Brownlee. [e-mail]
                        Pete More.      [e-mail]
                        Ian Taylor.     [e-mail]

The lecturer supervising the project is:-

                        Sunil Das.      [e-mail]

[Ed. This message was improperly sent to VALERT-L; please do not
respond to it there.  The author has been informed.]

------------------------------

Date: Thu, 9 Feb 89 13:16 EST
From: "Mark H. Anbinder" <[e-mail]>
Subject: RE: Request for info... Interferon 3.0 (Mac)

Interferon is telling you that the disk you are giving it is not an
HFS disk (not HPS).  HFS stands for Hierarchical Filing System, and is
the Macintosh disk format that is the current standard.  Before the
MacPlus came out, MFS (Macintosh Filing System) was the disk format.
The easiest way for the average user to tell the difference between an
HFS and an MFS disk is that the HFS disk holds 800K and the MFS disk
holds 400K.  In any case, the Interferon program can not check for
viruses on the old format, MFS disks.

If you want more information about the real differences between MFS
and HFS... an MFS disk is organized as a flat, single-level storage
space.  The folders are just provided to neaten the desktop.  In HFS,
the folders are actually logical subdirectories, much as you'd find on
an IBM PC, or on many mainframes (though NOT under CMS on an IBM
mainframe).  This allows you to group your files in ways that actually
matter when you're using your computer.  To tell whether a disk is MFS
or HFS (the 400/800K distinction is not universally true), look in any
of that disk's windows, at the double line below the title bar and
below the information about the number of files, the amount of space
available, and so forth.  At the extreme left of this double line, an
HFS disk has a pixel between the two lines, and an MFS disk does not.

Forgive me if this isn't clear... it's much easier to explain
graphically than in words!  I'll be happy to try again if anyone wants
more (or clearer) information.

Mark H. Anbinder
[e-mail]
THCY@CRNLVAX5

------------------------------

Date:         Thu, 09 Feb 89 15:13:33 EST
From:         Claude Goldman <[e-mail]>
Subject:      Protecting Public IBM PC's

I work for Computing and Information Services at Brown University.  We
have publicly  available PCs and   would like to protect then  against
virus and if that fails detect the presence of virus on hard disks and
floppys.  Can this  list   suggest either  PD/Shareware  or  Comerical
software?  Additional is there a way of testing  this software without
actually  infectiong  a machine?  Any  help  would be appreciated.  If
responses are sent to me I will gladly  summarize the results and post
them to the list to reduce network traffic.

Acknowledge-To: <[e-mail]>

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest              Friday, 10 Feb 1989         Volume 2 : Issue 43

Today's Topics:
Problems with Toshiba Laptop - virus? (PC)
Valentine's Day VTxxx trojan horse mail message
'ALERT'virus - short follow-up  (Mac)
Thanks & virus query (PC)
Information Requested
Apple 2 Elk virus

---------------------------------------------------------------------------

Date:     8-FEB-1989 14:44:41 GMT
From:     <[e-mail]>
Subject:  Problems with Toshiba Laptop - virus? (PC)

Dear Moderator:
   I am very new to your VIRUS-L mailing list, and still somewhat
unfamiliar with viruses in general. Recently, however, I have noticed
some peculiar behavior with my Toshiba 1200 Laptop computer. It seems
to throw random "h"s on the screen from time to time. At first, fairly
infrequently, and then increasingly more so. At this point it throws
"h"s, backspaces, spaces so often it's as if it has a mind of its own.
At present I am having the keyboard diagnosed at the dealer, but its
behavior did not give me the feeling that it was actually a keyboard
problem. Does any of this sound remotely familiar?
   Any help would be greatly appreciated.

Thanks in advance,
Bob Dooner
London School of Economics
([e-mail]1)

------------------------------

Date:         Thu, 9 Feb 89 17:54:00 EST
Sender:       Virus Alert List <[e-mail]>
From:         Gary Ansok <[e-mail]>
Subject:      Valentine's Day VTxxx trojan horse mail message

The following was posted on our local bulletin board, so we're
definitely getting into third- and fourth-hand information here.
This is really just a Trojan Horse rather than a virus, but I
thought I'd pass it along.

- ------------------------
Folks,
        What I am about to relate was triggered by a second-hand rumor,
but it reflects a very valid security concern and is something that we
may wish to deal with immediately.

        The rumor is that a Valentine's Day message has been prepared
that has the potential for causing lots of personal (and operational)
havoc.  Any user who reads this message, on a VAX system, using a
standard DEC terminal, will have all of his files deleted.  This little
nastygram is rumored to also put a sweet message and heart on the
screen while doing its dirty work.  A nice touch.

        At the risk of being alarmist, I suggest that we immediately
inform our users to be suspicious of any messages of unknown origin.
Information is limited and we do not know if it will appear or how to
recognize it if it does.  If I get more information I'll send it
along.
- -------------------------

I have a few questions for anyone who knows VTxxx terminals:

1)  Is it possible to do this on a VT1xx or VT2xx terminal?  I know it
        is possible to cause the answerback message to be echoed, but
        I don't know of a command to load the answerback message from
        the host; it is possible to load a definition into a (shifted)
        function key, but that requires the user to press the key;
        I know of no command to echo the contents of the screen back
        to the host as input.

2)  If it is possible, is there a setup option that will immunize the
        terminal from this particular disease?

This sort of attack has been known for years, especially on
forms-oriented terminals, but I had believed that my terminal (a
VT220) was not subject to this particular vulnerability.

Has anyone else heard about this?  Has anyone actually SEEN this
beast?  If you notice it ahead of time, it should be simple to
determine what it does and where it came from (unless it's
self-perpetuating like the XMAS EXEC -- but there's no easy list of
destinations on VAX/VMS).

        Gary Ansok
        <[e-mail]>   or   <[e-mail]>

P.S.  The lack of a way for this thing to hide its origins from anyone
        who is looking for it makes me wonder if it is real.  But I'll
        be looking over my incoming mail extra carefully for a few weeks
        anyway.  -- Gary

------------------------------

Date:     Fri, 10 Feb 89 01:25:00 GMT
Sender:   Virus Alert List <[e-mail]>
From:     Danny Schwendener <[e-mail]>
Subject:  'ALERT'virus - short follow-up  (Mac)

>PS:  I (David Richardson) have never actually seen this, & I honestly hope
>it is a hoax (like the "modem  virus"), but it is too scary to ignore.

I'm very afraid it isn't a hoax. I spent a good part of the afternoon
trying to reach Thierry Delettre and the DTS of Apple France. I
reached both of them. Below are some precisions. For those who want
general info, check the posting made a few days ago.

- - The virus adds 1344 bytes to the CODE ID=1 resource of an application
- - it has been purposely written to attack applications from Apple Inc.,
  and does this by checking if CODE ID=1 is named "Main". Other applications
  won't be infected. non-application files won't be touched by the virus.
- - the code segment starts with the following byte sequence: 6000 0028
  (this is BRA *+42 for those of you without sixteen fingers) and
  contains the four letters 'ANTI' (I think right after this first
  instruction, but I'm not sure - the line noise was terrible). Note that
  the CODE ID=1 resource also contains a 4-byte segment header, so check
  for the sequence in bytes 5-8.
- - It loves MultiFinder. Seems to propagate faster through MultiFinder than
  through a standard Finder environment.
- - Vaccine detects it only if the "Always Compile MPW INITs" is unchecked
  (could someone explain me why?)

I should get a copy of the bugger by the end of next week, if the french
postal service doesn't go on strike again. Expect a report soon.

- -- Danny Schwendener
   ETH Macintosh Support, ETH-Zentrum, m/s PL, CH-8092 Zuerich, Switzerland
   UUCP:     [e-mail]     BITNET:    [e-mail]
   Internet: [e-mail]   AppleLink: macman%czheth5a.BITNET@DASNET#

------------------------------

Date:         Thu, 9 Feb 1989 16:58 PAC
From:         Marty Zimmerman <[e-mail]>
Subject:      Thanks & virus query (PC)

Thanks to all of you who responded to my question about (c) Brain.
Your help is greatly appreciated.

Now I have another question about an unidentified virus (?).  This one
turned up in a department on campus when they were checking their disks
for (c) Brain.  The symptoms are as follows:

1) A strangely altered boot track (on 360K floppies) that Nortons says
is "not a boot track".  The machine appears to boot normally, though.
There are no messages that are obvious.  One of our Systems people is
currently disassembling it to find out what it does, but we do know that
it sets aside about 10K of RAM for itself before loading DOS.

2) Alterations to the FORMAT.COM file, if it exists on the contaminated
disk.  The only obvious change is the prompt that asks the user to
press ENTER to begin formatting.  Now it says "Press <-' to begin".
In other words, it tries to draw out the ENTER/RETURN symbol.

Are we just getting paranoid, or does this sound familiar to anybody?
None of the disks in this department showed any signs of (c) Brain
infection.

Thanks again for your comments.

Marty Zimmerman
Computer Services
University of Idaho
<MARTYZ@IDUI1>

------------------------------

Date:         Thu, 09 Feb 89 20:24:13 CST
From:         James Ford <[e-mail]>
Subject:      Information Requested

We are starting a Computer Post here, and one of the topics of
discussion will be viruses/trojans.  Does anyone have any suggestions?
The average age of the students involved is 14-17 (8th grade - 12th
grade).  Due to this, a "detailed" technical representation is not
necessary (and I probably wouldn't get it right, anyway..(grin)).

Please respond directly to me.

                       Thanks in advance,

                           James

P.S.  If someone has already done this to a similar age group, I would
      like to here from them.

Disclaimer:  Hacking can be fatal to your files.........

------------------------------

From:       The Heriot-Watt Info-Server <[e-mail]>
Date:       Fri, 10 Feb 89 10:32:14 GMT
Subject:    Apple 2 Elk virus

Re: Bruce Howells request for information on the elk cloner virus for
    the Apple 2, I enclose a copy of an article from USENET posted by
    <[e-mail]> on April 26 1988, giving further details. Hope
    this is of some use.


Here are descriptions of a virus and a nasty program header which run
on the Apple II family.

===============
                        The Elk Cloner V2.0

   I found the Elk Cloner V2.0 #005 on a disk of mine in 1981 or 82.
I'm fairly certain it could not have been written before the
publication of Beneath Apple DOS, so I would date it around
mid-1981...  It works exclusively with DOS 3.3.

THE VIRUS

1.  It is installed by booting an infected disk.  I'm not sure how it
initially gains control; apparently it is loaded in with some trash
from T0 SA which DOS loads for no apparent reason.  (BTW, since
HackerDOS rearranges DOS on the disk, the Cloner would trash it.  It
might trash master disks, I don't know.)  If you use a modified DOS
which marks T2 S3-8 as free for use (as HackerDOS does), it would
overwrite any file stored there.
   A JMP $9B00 which was installed when the disk was infected jumps to
this code (I think) and loads the virus from T2 S3-S8 into $9000-95FF.

2.  Next, it inserts its claws into DOS:
   A. Hooks into the Do Command code at $A180 and makes every command
reset the DOS parse state to 0.  I have no idea why it does this.  It
has no obvious effects.
   B. Hooks into the RUN, LOAD, BLOAD, and CATALOG commands to make
them check the disk accessed & infect it if necessary.
   C. Create a USR vector for the Cloner diagnostics:

B=USR(10)       Prints a cute poem:

ELK CLONER:
   THE PROGRAM WITH A PERSONALITY

IT WILL GET ON ALL YOUR DISKS
IT WILL INFILTRATE YOUR CHIPS
YES IT'S CLONER!

IT WILL STICK TO YOU LIKE GLUE
IT WILL MODIFY RAM TOO
SEND IN THE CLONER!

B=USR(11)       Prints ELK CLONER V2.0 #005 (version check)

B=USR(12)       Read the disk & prints BOOT COUNT: (#)

B=USR(13)       Infects a disk

3. Increments the boot count

4. Checks for any special event for this boot:

Boot # (hex)    Effect

A       Point reset vector to $FF69 (monitor)
F       INVERSE
14      Click the speaker
19      FLASH
1E      Switch letters at $B3A7-B3AA so filetypes T I A B will appear as
        I T B A
23      Change DOS signal character from ctrl-D to ctrl-E
28      Lockout the computer on reset (dangerous one!)
2D      Run the current program on any keypress (locks out the machine, also
          dangerous. BTW, this is done by setting the hibit of $00D6.)
32      Print above poem on reset
37, 3C, 46      Screw with the INIT code.  I think it will give you an I/O
          ERROR, but I haven't tried.  3C and 46 might be dangerous in that
          it might not init a whole disk.  I don't know.
41      'Crash' to monitor on every DOS command
4B      Reboot
4C      Reboot
4D      Reboot
4E      Reboot
4F      Write 0 to the boot count & start all over again!

5. Sits back & infects disks.

This is how the program is structured:
9000            Version number
9001-9073       Setup
9074-908F       [Check a disk for infection] code
9090-90D9       Replacement code for LOAD, BLOAD, & CATALOG
90DA-9178       [Infect] code
9179            Read VTOC
9181            Write VTOC
91A8            Print routine
91E4            Serial #
91E5            Marked with a 0/1 if a disk is infected/uninfected
91EC-9243       Diagnostics
9244-9328       Poem
9343-9435       Special events by boot count
9500-9532       Code which loads Cloner on boot
95E1-95FF       ASCII: MATT BE<ctrl-D>JOHN HINKLYJOHN HINKLE<ctrl-D>
                (The author's hero?)

These are within the VTOC:
B3BE    Zeroed, I don't know why
B3BF    Boot count
B3C0    Zeroed, don't know why
B3C2    Infection mark: Version number (=(9000))
   There may be several versions out.  The version number would be used so
later versions would write over older versions, for a new improved
infection.

THE TEST

Any of these methods will work:

1. Check T$11 S0 Byte 7. If it is non-zero, the disk might be infected.
2. Check T1 S0 B$80-82. If they are 4C 00 9B, you have the Cloner.
3. Check T2 S3 - T2 S8 for the Cloner.
4. From Applesoft, immediately after boot, enter B=USR(11).

THE VACCINE

   If you write a 2 to T$11 S0 Byte 7, Cloner version 2 will not
infect that disk. I have verified this.

THE CURE
   Write something (like 00:1 AD 88 C0 4C 59 FF) to sector 0 so you
can't boot that disk.

PRECAUTIONS
   The Cloner will not work unless you boot an infected disk.  It
cannot infect a write-protected disk.  I have infected disks I use all
the time.  Just mark them as infected & don't boot them.

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest              Friday, 10 Feb 1989         Volume 2 : Issue 44

Today's Topics:
Write protected disk (Mac + PC)
Virus detection
Virus Broadcast in Austria
Wide area network worms

---------------------------------------------------------------------------

Date: 10 Feb 89 17:31 +0100
From: Markus Mueller <muellerm%inf.ethz.ch@cernvax>
Subject: Write protected disk (Mac + PC)

Recently a virus (nVIR) has shown up on one of my disks for a
Macintosh although the floppy had been write protected at the time
virus got onto it. Therefore I would like to know:

1. Can the write protection mechanism on a Mac be overrided by software
   as it is the case for an IBM PC (controller PD765)?

2. Are any viruses (nVIR or other) around that exploit this?

3. Same questions, but for IBP PC and clones (including those that use
   the FE2100 floppy disk controller)

Thanks for your responses; I will post a summary.

   Markus Mueller
   Communication Systems Group
   ETH Zurich
   Switzerland

   [e-mail]
   [e-mail]

------------------------------

Date: Fri, 10 Feb 89 10:46:21 PST
From:     [e-mail]
Subject: Virus detection

A little future speculation here... currently we seem to be fighting a
losing battle against virus detection and as viruses improve it's
unlikely that that will change.  If we want the capability to download
shareware, etc, from bulletin boards, etc, then we must assume that we
cannot check the software for a virus with 100% success before running
it.  In general, you can't know the output of a program given the
input without running it, except in special cases.

We can check for *known* viruses; but how long before shape-changing
and mutating viruses hit the scene that defeat all practical
recognition techniques?

Maybe the quarantine approach is better.  Postulate a separate
computer for checking viruses on (perhaps some kind of virtual
machine).  This computer runs a meta-program that automatically runs
new programs with as many different environments and inputs as
possible (teaching the meta-program how to use the new program is left
as an exercise to the reader).  The system clock runs 1000 times
faster than normal to check for delayed-action viruses.

Comments, anyone?

Peter Scott ([e-mail])

------------------------------

Date:         Fri, 10 Feb 89 21:06:59 MEZ
From:         Konrad Neuwirth <[e-mail]>
Subject:      Virus Broadcast in Austria

We had a "virus-special" on the news today, and I wanted to tell you
some "new things" i "learned" from that programme.

They showed a "virus" (nobodyt who talks about viri publicly does
understand the difference virus-worm-trojan) that ate all the . (full
stop) symbols from the screen with a face. I can't type the IBM-PC
Ascii's face here, but i am sure you all know what I mean. It looked
like:

blablabla.                O (comment: approaching face).

Then, they showed one of the most harmful computer viri ever:
face.com. I am sure every user, especially those who read computer
magazines, will run to the virus-specialist immediatly if they see
that program on their screen.

Then they said that because of a computer, you have to "re-install the
computer". Hmm, that is really new to me. I only re-installed the
software when I was bitten.
Now here is the most important thing about viri: why they were
invented. I quote (translated):
"We find the roots of that problem some years back. Hackers broke into
big computer systems via phone, outsmarted electronic barriers and
cracked the copy-portection of programs. The marketplace got flooded
by illegal copies and the salesmen couldn't sell their original ones.
Loss was millions high. During the years, copying has become more
difficult. The hackers' answer: if not crakcing, at least disturbing.
That's why they invented viri."

Ain't that nice?

Another quote:"One way is via phone. A hacker dials into a net and
copies his virus into it. The other partner sees his screen
melting.." and they showed a amiga-screen melting.

They showed almost only amiga screens with well known "gadgets" which
are by no way viri, but can be found on every better public domain
collection.

Yeah, they showed one interesting virus:

A> (typetypetype)
 Oh no!
A> (typetypetype)
 You again!
A> (typetypetype)
 Go to hell!

That is a really nice virus, isn't it?

Has anyone ever seen a good programme about viri which only said true
things????????

btw: we have an austrian virus already. it was written here in vienna
and is known as the "falling letter" virus. When it is active, all
letters fall down to the last line. Has it been seen in the US already
or is it only in europe? (I can't send it, as I don't have it).

- -konrad

------------------------------

From:       David.J.Ferbrache <[e-mail]>
Date:       Fri, 10 Feb 89 11:45:37 GMT
Subject:    Wide area network worms

Re: the recent request for information on wide area network worms and
    other infections.

The three major cases which jump to mind are:

1. The internet worm - for which the main reference must be Gene
   Spafford's report "The Internet Worm Program: an analysis", which is
   available from Purdue University, Technical report CSD-TR-823, No
   1988.

2. The decnet worm - which affected the NASA SPAN/HEPNET network in
   December 1988, which contained sufficient safeguards to ensure that it
   did not cause the same crippling load problems evidenced by the
   Internet worm. The best reference for this is the DDN Management
   bulletin, No 50 23 Dec 1988, available from the SRI-NIC host usinf ftp
   login=anonymous, password=guest. Pathname
   DDN-NEWS:DDN-MGT-BULLETIN-50.TXT

3. The BITNET Christmas chain letter - the source of this chain letter
   has now been published actually in the recently cited "Computer
   Viruses- a high-tech disease" book. The source is on page 193. For
   those who haven't yet found it, and on the basis that a number of
   persons have already mentioned it existence, the citation is:

   Computer viruses, a high-tech disease
   R.Burger
   Published by Abacus, 5370 52nd Street SE, Grand Rapids, MI 49508
   ISBN 1-55755-043-3
   Priced at Seventeen pound,45 pence in the UK

A passing comment must be that the book provides an in depth review of
the Vienna virus, plus a number of the viruses developed by the Chaos
Computer club. I suspect that the book will become a reference for
Hackers and Administrators alike within a very short time, and hence
all I can suggest is that administrators make very certain that their
systems are innoculated against the Vienna virus strain.

Unfortunately, with the publication of virus source it is certain that
we can expect a large number of variant strains to appear within a
very short time. The existing approach of signature recognition is
unlikely to be satisfactory. I believe that both the Italian and
Vienna viruses have now been published in source form, and hence the
degree of expertise required to re-engineer the virus by modifying the
manipulation task must be recognised as being comparitively small.

The modification of an existing virus to incorporate a long term delay
(such as 6 months or even a year) coupled with a totally destructive
manipulation task (such as a FAT, Boot sector scribble followed by a
complete format) is a fairly simple task. Such an action would convert
even a crude virus strain such as the Lehigh 1 virus into a
devistating strain. (Eg the comment by Ken that the modified version
of the Lehigh virus is now far more dangerous due to modification of
the delay in activation of its manipulation task).

Dave Ferbrache                            Personal mail to:
Dept of computer science                  Internet <[e-mail]>
Heriot-Watt University                    Janet    <[e-mail]>
79 Grassmarket                            UUCP     ..!mcvax!hwcs!davidf
Edinburgh,UK. EH1 2HJ                     Tel      (UK) 031-225-6465 ext 553

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest              Monday, 13 Feb 1989         Volume 2 : Issue 45

Today's Topics:
Valentine's Day VTxxx DECNET virus
re: Alert against Possible VMS Virus/Trojan Horse
RE: Valentine's day trojan horse (VIRUS-L V2.n43) (VMS)
Re: Vt100 fun
Media: a different aspect

---------------------------------------------------------------------------

Date: Fri, 10 Feb 89 14:55:23 PST
From:     [e-mail]
Subject: Valentine's Day VTxxx DECNET virus

A warning about this rumored trojan horse was recently distributed
here and below is the analysis which I sent back:

- - - - - - - - -

I have to wonder about the validity of this claim.  The "answerback"
is a feature of VT100-compatible terminals that can be programmed in
SETUP mode and sent by pressing CTRL-BREAK; it can also be triggered
by the host with the control character ENQ (05).  The thesis of this
claim appears to be that the answerback is reprogrammed with a control
sequence, presumably to contain something of the form "^ZDEL
*.*;*<CR>" and then an ENQ follows, which causes the terminal to send
the answerback, which is interpreted as typed commands by the host, in
this case to exit MAIL and delete files.

The problem with this is that I can find no way of setting the
answerback with a control sequence.  The VT100 and VT240 programmer's
guides, while notoriously poorly-indexed and arranged, are mum on this
point.  The Pericom MG400 (VT100-compatible) manual is more explicit;
it states that there is *no* way to program the answerback remotely.
This makes sense, in that the answerback is intended to be a function
of that specific terminal and there would be no reason to want the
capability to change it from a remote location.

All control characters can be sent in mail messages, so it is possible
to send the ENQ.  For that matter, you can send a ^S and freeze
someone's terminal so they have to reset it to get it working again
(of course, I have never done anything like that...).  However, I
don't think there is any way to change the answerback message from the
host and therefore I disbelieve this claim.

It *may* have happened at another site when some malicious user gained
access to another person or persons' terminal(s) and reprogrammed
their answerbacks to the string I described above *from the keyboard*
(which does not require any account access), then sent the message out
so that it would be read by users once they were logged in, when the
answerback could affect their account just as if they had typed the
commands themselves.

Peter Scott ([e-mail])

------------------------------

Date: Fri, 10 Feb 89 18:39 EST
From: "Jerry Leichter ([e-mail])" <LEICHTER@YaleVMS>
Subject: re: Alert against Possible VMS Virus/Trojan Horse

I'm including more text than I normally do because of the nature of this
message.

   [LT Stuart L Labovitz reports:] I am forwarding the following message,
   in full, from the VALERT virus alert mailing list.  I do not know if
   this is a valid message, or even if such a trojan could be
   constructed, but definitely want to pass the warning along to all the
   Info-Vaxers out there.  Please send copies of any comments on this
   warning to the original author (address at the end of the message), as
   to myself.  I will forward any comments I receive to the Virus-L
   mailing list at Lehigh University ([e-mail], moderator
   is Ken Van Wyk, [e-mail] or [e-mail]).

   ================ORIGINAL MESSAGE FOLLOWS==============================

   The following was posted on our local bulletin board, so we're
   definitely getting into third- and fourth-hand information here.  This
   is really just a Trojan Horse rather than a virus, but I thought I'd
   pass it along.

   ------------------------
   Folks,
   What I am about to relate was triggered by a second-hand rumor,
   but it reflects a very valid security concern and is something that we
   may wish to deal with immediately.

   The rumor is that a Valentine's Day message has been prepared
   that has the potential for causing lots of personal (and operational)
   havoc.  Any user who reads this message, on a VAX system, using a
   standard DEC terminal, will have all of his files deleted.  This
   little nastygram is rumored to also put a sweet message and heart on
   the screen while doing its dirty work.  A nice touch.

   At the risk of being alarmist, I suggest that we immediately
   inform our users to be suspicious of any messages of unknown origin.
   Information is limited and we do not know if it will appear or how to
   recognize it if it does. If I get more information I'll send it along.
   -------------------------

   I have a few questions for anyone who knows VTxxx terminals:

   1)  Is it possible to do this on a VT1xx or VT2xx terminal?  I know it
           is possible to cause the answerback message to be echoed, but
           I don't know of a command to load the answerback message from
           the host; it is possible to load a definition into a (shifted)
           function key, but that requires the user to press the key;
           I know of no command to echo the contents of the screen back
           to the host as input.

   2)  If it is possible, is there a setup option that will immunize the
           terminal from this particular disease?

   This sort of attack has been known for years, especially on
   forms-oriented terminals, but I had believed that my terminal (a
   VT220) was not subject to this particular vulnerability.

   Has anyone else heard about this?  Has anyone actually SEEN this
   beast?  If you notice it ahead of time, it should be simple to
   determine what it does and where it came from (unless it's
   self-perpetuating like the XMAS EXEC -- but there's no easy list of
   destinations on VAX/VMS).

            Gary Ansok
                <[e-mail]>   or   <[e-mail]>

   P.S.  The lack of a way for this thing to hide its origins from anyone
           who is looking for it makes me wonder if it is real.  But I'll
           be looking over my incoming mail extra carefully for a few
           weeks anyway.  -- Gary


   =============END OF ORIGINAL MESSAGE==================================

This "rumor" is a wonderful example of a kind of "denial of service"
virus.  It infects the "wetware" of susceptible users.  Different
forms of this rumor have been floating around for several days now;
they've been passed around internally to DEC, for example.

There is NO truth behind this rumor.  What it describes is impossible,
for several reasons:

   a)  The VMS MAIL program filters out escape and control sequences
           when presenting mail to the user.  Even if there were a
           sequence which could cause damage, it can never reach the
           terminal as long as you use only READ to look at the message.

           It is theoretically possible, I suppose, that some non-ANSI-
           compatible terminals may be triggered by some sequence of
           characters that MAIL considers to be "just text", and so might
           be vulnerable.  But I doubt it.

   b)  A message COULD suggest that you type EXTRACT TT:, which would
           copy the message unfiltered to your terminal.  This trick
           is often used to send, say, ReGIS pictures through the mail.
           Obviously, this is a deliberate action - you have to be wil-
           ling to do it.  Just on general principles, you should NOT do
           this with a message from someone you don't know.

           A message could also tell you:  Type EXTRACT FOO.COM, CTRL/Z,
           and @FOO.  If you go ahead and do that,  you will create and
           execute a command file which could do anything at all.

           Then again, the message COULD tell you "Shoot yourself in the
           head".

   c)  No mainline DEC terminal allows you to set the answerback message
           from the host; it can be changed only in SETUP.  (And, no, you
           can't put the terminal into SETUP from the host.)  I know the
           people who designed every DEC terminal since the VT100, and
           worked on some of the designs, so I'm 100% certain of this.
           I include the "mainline" qualifier only because there are so
           many variations, mainly in international markets, which I know
           nothing about that I can't make an absolute statement.  But I
           would be very surprised if you could do this on ANY DEC ter-
           minal.

   d)  UDK's (User Defined Keys) are a slightly different story.  You can
           load them from the host but:

           1.  It is impossible for the host to force the terminal to
                   send the contents of a UDK - you must deliberately
                   type SHIFT with a function key to get the value sent.

           2.  When you load UDK's, you may ask the terminal to "lock"
                   them.  Once the UDK's are locked, any further attempts
                   load them are ignored.  Nothing the host sends can
                   unlock the UDK's - it can be done only from SETUP or
                   by power-cycling the terminal.

           If you don't use UDK's, (1) should protect you.  If you DO use
           UDK's, (2) can protect you (though you have to make sure you
           lock the definitions).

           Again, I can speak only of "mainline" DEC terminals.  One com-
           mon request is for the ability to have the UNSHIFTED function
           keys send the UDK sequences.  This has never been done in a
           mainline DEC terminal; one reason is that it could make a user
           who doesn't normally use UDK's, but DOES use the function
           keys, vulnerable.  Of course, if the choice of operational
           mode could be made only in SETUP, you'd still be safe.

   e)  Several DEC terminals support block mode.  I believe the VT131
           and VT132 and the VT330 and VT340 are the only "mainline"
           terminals that do so.  It MAY be possible to force such a
           terminal to send back data from the screen, in which case an
           attack of the nature being discussed here is possible.  I'm
           not absolutely certain, and the situation may be different
           on the different models.  What it comes down to is this:
           There is no defined sequence which tells the terminal to
           send data from the screen to the host; rather, such action is,
           in the documented cases, always initiated by the user typing
           something, usually ENTER.  However, it is possible to operate
           these terminals in a mode in which ENTER sends a "data ready
           for you" message, and the host then replies with "OK, send
           it".  What isn't clear is what happens, in all circumstances,
           if the host sends "OK, send it" when the terminal hasn't indi-
           cated it has data.  Probably nothing, but I can't guarantee
           that.

           In any case, on the VT330 and VT340, there is a SETUP option
           which disables block mode, so this becomes a non-issue.

   f)  ReGIS supports ways for the host to do some pretty complex things
           on the terminal, and get reports back.  It MAY be possible to
           use ReGIS for this kind of attack.  I've never seen a defini-
           tive analysis either way.

   g)  The VT220 (and VT320) support neither block mode nor ReGIS, and
           as far as I know are not vulnerable to this kind of attack.
           (The same goes for most VT100-generation terminals.  Some of
           them had firmware bugs which allowed "letter bombs" to disrupt
           the terminal, but none of those do anything permanent, or harm
           the connected system.)

   h)  The above applies ONLY to DEC terminals.  If you have a "DEC-com-
           patible", you have to read its documentation very, very care-
           fully to determine if you are safe.  Some compatibles try to
           "improve" on the original terminals by adding such "over-
           looked" features as escape sequences that let you program the
           answerback message from the host, or read arbitrary stuff from
           the screen.  Such "improvements" could leave you wide open.

           I have no particular compatibles in mind here - there may not
           actually BE any which have made this kind of change.  But to
           be safe, you have to be wary.  I'd be ESPECIALLY wary of ter-
           minal emulation programs running on PC's - they often have the
           opportunity to provide all sorts of nifty, but dangerous,
           features which the hardware manufacturers find too expensive
           to include.
                                                        -- Jerry

------------------------------

Date:         Fri, 10 Feb 89 19:48:00 EST
From:         "Hamid A. Wasti" <[e-mail]>
Subject:      RE: Valentine's day trojan horse (VIRUS-L V2.n43) (VMS)

> Is it possible to do this on a VT1xx or VT2xx terminal?  I know it is
> possible to cause the answerback message to be echoed, but I don't
> know of a command to load the answerback message from the host; ....

If I recall correctly, there was a discussion about this on the RISKS
FORUM a while back (most probably a year or 2 ago).  If my memory
serves me correctly, I believe someone claimed that most dumb
terminals (not just the VTxxx's) could be made to echo a given message
back to the host through undocumented features/bugs.  Perhaps someone
who recalls the discussion better or who has easy access to RISKS
archives could give us more details.

     -----Hamid A. Wasti
          <[e-mail]>

P.S.  How does one distinguish between an undocumented feature and a
bug ?

------------------------------

Date:         Fri, 10 Feb 89 22:18:54 EST
From:         Dan Bornstein <[e-mail]>
Subject:      Re: Vt100 fun

Someone was wondering about the ability to have the VT100 series send
info from the screen. Yes, it is indeed possible: In order to type a
given character/ string, one positions the cursor on the (previously)
printed whateverness, and uses either the send-character or send-line
escape sequence. I know this back in my youth (high school), I played
around with the school's Tandy 6000 (I take what I can get), a Xenix
machine. I used the above trick to issue "cds" that would have lasting
effects (after a Xenix script ends, the current directory is reverted)
from scripts (to be executed as commands). Admittedly there are better
ways, but I didn't know them.  So much for nostalgia.

- -dan

------------------------------

Date:         Sat, 11 Feb 89 17:38:39 EST
From:         Neil Goldman <[e-mail]>
Subject:      Media: a different aspect

I was just paging through "Business Today", a magazine mailed to
college students around the country, and stumbled upon the following
ad:

Under a picture of a 3M data cartridge it read: "Until There's a Cure
For Computer Viruses, Take One Of These And Get Back To Work."  Under
that, in smaller type, read: "Today, with the spread of computer
viruses and data parasites threatening the health of American
business, you have to protect yourself.  If you network, be sure to
back up your work routinely on 3M data cartridge tape before a virus
enters your systems."  Then it lists an '800' number to call for info.

First, I hope noone thinks I am trying to use Bitnet for commercial
use -- I'm not.  I have no affiliation with 3M.

I am all for encouraging users to institute systematic, periodic
backup procedures.  However, ads like this compound the user confusion
we have (to some extent) been blaming on the media -- that if you
perform regular backups you are safe.

It is unfortunate that our counterparts in industry are not assisting
in rectifying the (perhaps unsolvable, yet certainly *not*
unimprovable) problem.

- - Neil

- ------------------------------------------------------------------------
Neil A. Goldman                        [e-mail]

Replies, Concerns, Disagreements, and Flames expected.
Mastercard, Visa, and American Express not accepted.
Acknowledge-To: <NG44SPEL@MIAMIU>

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest             Tuesday, 14 Feb 1989         Volume 2 : Issue 46

Today's Topics:
re: Virus detection
re: "Valentine's Day Trojan Horse" (VAX/VMS)

---------------------------------------------------------------------------

Date: 13 February 1989, 10:02:09 EST
From: David M. Chess  <[e-mail]>
Subject: re: Virus detection

> currently we seem to be fighting a
> losing battle against virus detection

Are we?  In practice, the existing viruses are all very
unsophisticated, and easily detected by things that watch for
suspicious activity in the environment (executables changing length,
modifications to system files, new resources appearing, and so on).
It's not hard to write a program that will detect every known virus,
*and* every other virus in the general families that we've seen.  In
theory, of course, viruses >could< be a lot nastier, and I'm not
advocating ignoring the threat.  But I don't think we're losing the
battle at the moment...

> Maybe the quarantine approach is better.

No better than the modification-detection approach, I don't think.
They might be used together to some advantage, but I think trying to
reply entirely on "quarantine" would be a serious mistake.  Unless you
try very very hard, it's going to be trivial for the virus to notice
that the machine it's running on is not "normal" in any sense ("hmm,
thirty-five programs have been run without a single keystroke on the
physical keyboard; rather suspicious!").  A virus could be designed
not to do any infecting unless the environment looked normal (physical
keystrokes occurring now and then, a certain amount of idle time,
etc).  For every step you can take to make the quarantine environment
look more normal, a new virus can come out that is one step cleverer.
Same sort of escalation that could occur in the area of non-quarantine
methods of detection!

> The system clock runs 1000 times
> faster than normal to check for delayed-action viruses.

If you speed up the CPU by a factor of 1000 as well, it will burn out
(if you're using a normal machine), or be very very expensive (if
you've found someone who can make a CPU that'll run 1000 times faster
than today's, I think lots of computer companies would be
interested!).  If you don't speed up the CPU, but only the time-of-day
clock, the fact will be very obvious to any virus testing to see if
it's running in quarantine.

> Comments, anyone?

You asked for it!   *8)

DC

------------------------------

Date: 13 Feb 89 20:23
From: [e-mail] (Repent! Godot is coming soon! Repent!)
Subject: re: "Valentine's Day Trojan Horse" (VAX/VMS)

In Virus-List 2.43, Gary Ansok asks whether a program on a host
computer can change the VT100/VT200 answerback message or echo screen
contents back to the host.

Neither is possible in VT100 or VT200 series terminals.  Also, the VMS
mail display program filters out all escape sequences and non-standard
control codes.

Thus, a Trojan Horse program distributed via VMS Mail would have to
tell the user to save the file and execute it.

In a postscript, Gary notes that he'll "be looking over [his] incoming
mail extra carefully for a few weeks."  This is always good advice.

Martin Minow
[e-mail]
The above does not represent the position of Digital Equipment
Corporation.

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest             Tuesday, 14 Feb 1989         Volume 2 : Issue 47

Today's Topics:
Valetine's Day trojan horse (VAX/VMS)
Re: Valentine's Day VTxxx trojan horse mail message (VAX/VMS)
VIRUS-L LISTSERV files now available via anonymous FTP

---------------------------------------------------------------------------

Date:     Tue, 14 Feb 89 11:21 EST
From:     Cincinnati Bengals. <[e-mail]>
Subject:  Valetine's Day trojan horse (VAX/VMS)

     This rumor is an obvious attempt to capatilize on the virus
hysteria and cause people to be afraid to do anything on the computer.
I'd be willing to bet money that it's impossible that when a mail
message is read, the message causes files to be deleted.  Either the
rumor was improperly relayed, or someone is trying to cause fear in
VAX/VMS users all over by spreading an absolutely absurd rumor.

Tom Kummer

------------------------------

Date: Tue, 14 Feb 89 13:10:16 est
From: Stuart Labovitz <[e-mail]>
Subject: Re: Valentine's Day VTxxx trojan horse mail message (VAX/VMS)

In order to get some "expert" opinions on this virus/trojan alert, I
forwarded a copy of the VALERT message to the Info-VAX mailing list
([e-mail]).  Jerry Leichter has responded directly to
VIRUS-L, but appended below is another response (refering to Jerry's
message) from Stephen Dowdy.  I will forward any other relevant
responses on to VIRUS-L, as well.

                                LT Stuart L Labovitz
                                USAF Electronic Technology Laboratory
                        arpa:   [e-mail]

                           I bark, therefore I am.
                                          --Descarte's dog

= = = = = = = = = = message from Stephen Dowdy follows = = = = = = = = = = =

[e-mail] ("Jerry Leichter ") writes:

]    The rumor is that a Valentine's Day message has been prepared
]    that has the potential for causing lots of personal (and operational)
]    havoc.  Any user who reads this message, on a VAX system, using a
]    standard DEC terminal, will have all of his files deleted.  This
]    little nastygram is rumored to also put a sweet message and heart on
]    the screen while doing its dirty work.  A nice touch.
]
]This "rumor" is a wonderful example of a kind of "denial of service"
]virus.  It infects the "wetware" of susceptible users.  Different
]forms of this rumor have been floating around for several days now;
]they've been passed around internally to DEC, for example.
]
]There is NO truth behind this rumor.  What it describes is
]impossible, ...

(there is a lot of truth to the concept.  DO NOT BLOW THIS OFF AS
IMPOSSIBLE)

]  a)  The VMS MAIL program filters out escape and control sequences
]       when presenting mail to the user.  Even if there were a
]       sequence which could cause damage, it can never reach the
]       terminal as long as you use only READ to look at the message.

VMS Mail did not always filter out control characters.  I remember
reading (in 3.7 i believe) a mail file of the famous Champagne Glass
Line drawing set animation.

]  b)  A message COULD suggest that you type EXTRACT TT:, which would
]       copy the message unfiltered to your terminal.  This trick
]       is often used to send, say, ReGIS pictures through the mail.
]       Obviously, this is a deliberate action - you have to be wil-
]       ling to do it.  Just on general principles, you should NOT do
]       this with a message from someone you don't know.
]
]       A message could also tell you:  Type EXTRACT FOO.COM, CTRL/Z,
]       and @FOO.  If you go ahead and do that,  you will create and
]       execute a command file which could do anything at all.
]
]       Then again, the message COULD tell you "Shoot yourself in the
]       head".

Then again, the people who are hit by this form of trojan horse are not
generally computer literate.  If the message does say
        EXTRACT/NOHEAD FOO.COM
the user *WILL* do it.

]   d)  UDK's (User Defined Keys) are a slightly different story.  You can
]       load them from the host but:
]
]       1.  It is impossible for the host to force the terminal to
]               send the contents of a UDK - you must deliberately
]               type SHIFT with a function key to get the value sent.
]
]       2.  When you load UDK's, you may ask the terminal to "lock"
]               them.  Once the UDK's are locked, any further attempts
]               load them are ignored.  Nothing the host sends can
]               unlock the UDK's - it can be done only from SETUP or
]               by power-cycling the terminal.
]
]       If you don't use UDK's, (1) should protect you.  If you DO use
]       UDK's, (2) can protect you (though you have to make sure you
]       lock the definitions).

Ah, but again, the kind of user who falls for this type of trojan
horse is not literate enough to know these things.  It doesn't matter
how many ways there are to divert mal-intented individuals, the common
user is not going to use them. (and *someone* will have to restore
their files, or the OS if the person has privs)

]       In any case, on the VT330 and VT340, there is a SETUP option
]       which disables block mode, so this becomes a non-issue.

(once again... Joe User may not even know how to use SETUP.)

]       I have no particular compatibles in mind here - there may not
]       actually BE any which have made this kind of change.  But to
]       be safe, you have to be wary.  I'd be ESPECIALLY wary of ter-
]       minal emulation programs running on PC's - they often have the
]       opportunity to provide all sorts of nifty, but dangerous,
]       features which the hardware manufacturers find too expensive
]       to include.
]                                                       -- Jerry

Back in the days of 4.2 BSD Unix, when the ttys weren't protected by
group ownership 'ttys', i wrote a program exploiting a "feature" of
the Televideo 912/910 that allowed one to write to a user's terminal
(in BSD, if they had MESG Y), and have the terminal send that command
back.  Needless to say, any person with mesg y, and root on a tvi was
asking the system to go down.  (i never use any of these things for
malicious purposes, just to get the point across to people that there
are *MANY* non-obvious ways to break security).

Though, i agree that this reported trojan horse is probably not real,
in it's reported form, it is *VERY* real as a general security issue.
If i download your keys with a string, and you press that key, you're
are in trouble.  And no amount of convincing is going to make
non-knowledgable users do what they should (lock keys, reset the
terminal before logging in...; heck, i don't even do these things,
since it is such a pain)

Take a word of caution from the message.  It is possible to do these
things.  (and though i would really like to make my process name in
double wide characters for show users, i understand DECs approach to
dropping out control characters, it is probably the correct approach
in dealing with overly-"smart" terminals)

- --stephen
- --
$!#######################################################################
$! stephen dowdy (UNM CIRT) Albuquerque, New Mexico, 87131 [phone]
$! Usenet:   {convex,ucbvax,gatech,csu-cs,anl-mcs}!unmvax!charon!sdowdy
$! BITNET:   sdowdy@unmb
$! Internet: [e-mail]
$!      Team SPAM in '87!            SPAAAAAAAAAAAAAAAAAAAAMMMMMMM!
$!#######################################################################

= = = = = = = = = = message from Stephen Dowdy ends = = = = = = = = = = = =

------------------------------

Date: Tue, 14 Feb 89 14:06:35 est
From: ubu![e-mail]
Subject: VIRUS-L LISTSERV files now available via anonymous FTP

Internet (including ARPAnet, MILNET, NSFNET, etc.) users can now
access the VIRUS-L archives and backlogs via anonymous FTP to
IBM1.CC.LEHIGH.EDU.

Once logged in, issue a CD (or CWD) command to connect to either
VIRUS-L (for the log files) or VIRUS-P (for the archive programs).
At that point, the standard GET command will retrieve files, and the
DIR command will list available files.

The anonymous FTP is very new on our VM/CMS machine, so please report
any problems to me.  We currently know of some quirks when FTPing from
Sun workstations - it takes several commands before anything happens.
It has successfully been tested from other machines, however,
including VAX/VMS (CMU TCP/IP) and Zenith PCs (NCSA TCP/IP).

I hope that this adds to the functionality of the forum somewhat, even
though loading files onto the LISTSERV filelist is still as difficult
as ever...

Ken van Wyk

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest            Wednesday, 15 Feb 1989        Volume 2 : Issue 48

Today's Topics:
RE: VT100 emulation (Commodore 64)
MIT virus paper available for anonymous ftp (Internet)
DECNET VTxxx trojan horse
Re: 3M ad
Authentication
help on VIRUS-L archives

---------------------------------------------------------------------------

Date: Tue, 14 Feb 89 17:36 EST
From: [e-mail]
Subject: RE: VT100 emulation (Commodore 64)

I am completely familiar with one of the popular VT100/VT102/VT52
emulators for the Commodore 64 (EMULATOR.100, Allegheny Software
Works, P.O. 7103, Pgh., PA 15213).  This is a standard emulator that
follows the DEC manual--there is NO WAY to set the answerback message
from the host site.  There is also NO WAY to echo text from the screen
back to the host--I don't think "send character" and "send line" are
part of VT100/VT102 or VT52--don't know about the VT131's though.
Also, the function keys/user defined keys can ONLY be programmed from
the terminal side.

Certainly any emulator that allows the host to reprogram its
answerbacks/user defined keys is wide open to attack!

------------------------------

From: Jon Rochlis <[e-mail]>
Date: Tue, 14 Feb 89 18:13:06 EST
Subject: MIT virus paper available for anonymous ftp (Internet)

The MIT paper on the Internet virus of last Novemember, "With
Microscope and Tweezers: An Analysis of the Internet Virus of November
1988", is now available via anonymous ftp from either bitsy.mit.edu
(18.72.0.3) or athena-dist.mit.edu (18.71.0.38) in the pub/virus
directory as mit.PS (and mit.PS.Z). A version of this paper will be
presented at the 1989 IEEE Symposium on Research in Security and
Privacy.

        -- Jon

Abstract:

In early November 1988 the Internet, a collection of networks
consisting of 60,000 host computers implementing the TCP/IP protocol
suite, was attacked by a virus, a program which broke into computers
on the network and which spread from one machine to another.  This
paper is a detailed analysis of the virus program itself, as well as
the reactions of the besieged Internet community.  We discuss the
structure of the actual program, as well as the strategies the virus
used to reproduce itself. We present the chronology of events as seen
by our team at MIT, one of a handful of groups around the country
working to take apart the virus, in an attempt to discover its secrets
and to learn the network's vulnerabilities.

We describe the lessons that this incident has taught the Internet
community and topics for future consideration and resolution.  A
detailed routine by routine description of the virus program including
the contents of its built in dictionary is provided.

------------------------------

Date: Tue, 14 Feb 89 11:52:15 PST
From:     [e-mail]
Subject: DECNET VTxxx trojan horse

Thanks to Jerry for his comprehensive posting.  Apologies for an error
in mine: I had stated that it was possible to send any control
character in a MAIL message.  Well, you can, but it won't be displayed
on the screen; all are converted to $ signs except for the following:

BEL BS  HT  LF  CR  FS  GS  RS  US  DEL

although if you EXTRACT the message all control codes are left intact.
Evidently DEC installed the filtering since I last tried sending
control characters in MAIL messages, when it *was* possible, for
instance, to send a control-S.  The worst that appears possible with
the above set of codes is that some terminals will enter graphics
mode.

It is indeed fortunate that ESC cannot be sent, because I just
discovered that my VT220 compatible supports commands for both
programming and ordering transmission of PF keys!  I tried it.  It
gave me a shudder.  There is a SETUP option to lock the PF keys, but
it doesn't work.  Sigh...

Years ago I used a Sigma graphics terminal which was put into graphics
mode by the `escape sequence' "+-*/".  Fortunately it wasn't possible
to do anything other than draw pretty pictures after that point.

Peter Scott ([e-mail])

------------------------------

Date:     Tue, 14 Feb 89 18:56 EST
From:     <[e-mail]>
Subject:  Re: 3M ad

Neil Goldman <[e-mail]> writes:
>I was just paging through "Business Today", a magazine mailed to
>college students around the country, and stumbled upon the following
>ad:
>
>Under a picture of a 3M data cartridge it read: "Until There's a Cure
>For Computer Viruses, Take One Of These And Get Back To Work." ...
>
>It is unfortunate that our counterparts in industry are not assisting
>in rectifying the (perhaps unsolvable, yet certainly *not*
>unimprovable) problem.

Agreed.  I for one was particularily disappointed to find that 3M was
behind this.  Having been acquainted with a number of 3M people over
the years, I got the impression that theirs was not a company to
advertise or promote themselves in such a way.

The thing I find worst about it is that they are not only promoting
backups as a cure for virii, but plugging THEIR OWN BRAND as a cure,
as if their tapes were somehow virus-proof or immune.  While this may
sound ridiculous to us, I have worked with enough people who have a
hard time knowing what to do with an "OFF" switch to know that some of
them are going to think this and interpret the ad that way.  I'd just
like to see it when they get a call from somebody whose backups got
infected and screams "I thought your tapes were immune!".

As a matter of personal opinion, I have just about tossed the
commercial companies who deal with viruses and prevention on the heap
with the media.  Most of the good, usable anti-virals I have seen have
been shareware or PD utilities done by somebody who was stung
themselves and wrote it to protect themselves and help out those in
similar straits. Put it another way, they did it to help the problem,
not make a buck off it.

- --Steve
- ---------------
Steve Okay  [e-mail]/[e-mail]/CSR032 on The Source
                                 |____|
                                   |____New address, please do not send mail
                                        to "[e-mail]" that
                                        account is dead

           "Despite Colorization, MSDOS, and lights at Wrigley Field,
            One can still take comfort in the fact that no one is known
            to have run COBOL under UNIX"

------------------------------

From:       David.J.Ferbrache <[e-mail]>
Date:       Tue, 14 Feb 89 14:50:45 GMT
Subject:    Authentication

My recent request for information has raised an interesting problem,
basically who on a public list can be trusted with potentially
sensitive information concerning the functional principles of known
viruses, or indeed for that matter with disassembled or object code
versions of the virus.

Unfortunately, being a researcher at a UK university precludes most of
the traditional techniques such as personal contact at conferences.
You try persuading my Department to pay for a trip to the US on a
matter unrelated to my full-time job (ie Part time Phd work).

Equally, when I complete my report the question of who should I send a
potentially useful reference on viruses to. The method suggested by
two of my respondents is that of a letter on Departmental notepaper, I
suspect that this is not foolproof, and the difficulty involved in
either obtaining University notepaper or producing an authentic fake
notepaper is comparitively small.

The recent case of the Modem virus hoax also points towards the need
for a list of recognised researchers in the field. (A recent article
in the FIDONET news reviewed at great length the difficulties arising
from untrusted software, together with suggestions for digital
signatures).

So in summary, unless anyone has any good ideas concerning
authentication, is there such a thing as a list of active researchers
in the field, preferably also indicating their area of specialisation?


PS. Thanks to everyone on the list who responded to my original request for
    information. Since that time I have found another 5 forms of Amiga
    viruses, and 4 Apple II viruses. Before anyone asks for details of these,
    I am still waiting on additional information. I think that now makes
    37 virus strains and variants for Micros, together with a number of
    Mainframe system viruses, worm and chain letters.

    If anyone is in the process of collating a list of extant viruses please
    get in touch, and we can arrange to pool our information.

Dave Ferbrache                            Personal mail to:
Dept of computer science                  Internet <[e-mail]>
Heriot-Watt University                    Janet    <[e-mail]>
79 Grassmarket                            UUCP     ..!mcvax!hwcs!davidf
Edinburgh,UK. EH1 2HJ                     Tel      (UK) 031-225-6465 ext 553

------------------------------

Date:         Wed, 15 Feb 1989 18:22:00 SIN
From:         Thomas Tong <[e-mail]>
Subject:      help on VIRUS-L archives

Hi ...

     I would like to enquire how I can get back-dated issues of the
virus-l digests that ( apparently ) were not distributed to the BITNET
sites...

     I checked several nodes ( eg. LEHIIBM1 ) for the archives but
there are some issues missing...

     The latest "missing" issue that I did not receive ( and a whole
lot of other people too ) is V2 issue 01...

     Hope that you can assist me in this matter. Thank you!

Thomas Tong
[e-mail]

[Ed. VIRUS-L originates on a BITNET/Internet node, IBM1.CC.LEHIGH.EDU
(aka LEHIIBM1.BITNET).  It is directly distributed to both BITNET and
Internet.  Thus, all of the back-dated issues were sent to both.
There is no V2I1, however.  Actually, there is, but it contains one
"welcome back from the holidays" message from me - it was sent but
never distributed while were were having some LISTSERV related
problems.  When the problems were fixed, I never re-sent that digest
since it contained no useful information.  The LISTSERV archives here
on LEHIIBM1 contain 100% of the contributions to VIRUS-L - unedited.]

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest             Thursday, 16 Feb 1989        Volume 2 : Issue 49

Today's Topics:
Info on virus reported in Comm. of the ACM?
Virus-Group
Request for info about Atari viruses.
Appleshare Network Security
Another Anonymous FTP host for VIRUS-L archives

---------------------------------------------------------------------------

Date:     Wed, 15 Feb 89 01:11 EDT
From:     <[e-mail]>
Subject:  Info on virus reported in Comm. of the ACM?

        Does anyone know anymore information about the virus reported
in the February 1989 volume 32 number 2 page 274 issue of the
Communications of the ACM?  According to the article:

        "A hardware-induced computer virus could potentially affect 25
million microcomputers, according to a recent discovery by researchers
at NOVA University and ErrorNot Corporation.  The researchers say the
viruse is the result of faulty programming in the microcode of a
device used in computers.  Research indicates this viruse causes data
corruption, and its random pattern of attack with small data
destruction makes is difficult to identify.  The virus's dormancy
period varies from weeks or months to even years."

        The article then proceeds to give an address at NOVA where you
can send five dollars and receive a report of their findings
(TR-881101-1).  Does anyone know anything about this?  It is news to
me and the article offers no insight.

                                Mark James Burge
                                MJBURGE@OWUCOMCN

------------------------------

Date: Wed, 15 Feb 89 17:01:46 +0100
From: [e-mail]
Subject: Virus-Group

University of Dortmund
Department of Computer Science
Software Technology Laboratory
Sanjay Dewal

Postbox 500 500
D-4600 Dortmund 50
W.Germany

Hallo,
        in the readnews comp.os.vms I read that there exists a group
especially on the subject of Virus. Is it possible to get more
information of this group? Could I get into this group in order to get
the informations passed around as well?
        I am a system manager myself. Therefore I'm interested in news
on Viruses.
        Thanks in advance.
Bye
Sanjay Dewal

([e-mail] or [e-mail])

------------------------------

Date:    Wed, 15 Feb 89 01:11 EST
From:    "Scott P Leslie" <[e-mail]>
Subject: Request for info about Atari viruses.

Hello,
   Could someone please send me information concerning viruses on the
Atari ST computers.  I just started using PD software so I would like
to have knowlegde of possible infections to my system.
- --
Thanks,  Scott P. Leslie (UNCSPL@UNC)

------------------------------

Date: Wed, 15 Feb 89 10:21 EST
From: Roberta Russell <[e-mail]>
Subject: Appleshare Network Security

I manage a Macintosh network running AppleShare 2.0 FileServer and
PrintServer.  Users on the network have the option of downloading
server software or using their own.  All printing jobs, regardless of
software, are spooled to the server.

I am the only person enabled to write to the server.  Yesterday, while
doing backups, I noticed three new document files in the system
folder:
                                      (creator)  (type)
               0Aldus1.2Prep    36k     asps      lspt
               0Aldus1.2PrepS    6k     asps      lspt
               0Aldus1.2Prep     0k     asps      lsqt

The files were in a new print queue folder called Q_0aserWriter II_*
together with the usual queue and log files for the LaserWriter.  They
appear to have been created by the server software, but how and why is
a mystery to me.

PageMaker is not a program on the server.  Someone obviously has used
an outdated (and probably pirated) copy to do some printing.  I called
Aldus to find out how a their prep file and dictionary could be copied
to a write-protected server.  They had no idea.  Since there is now a
virus (INIT 29) that attaches itself to documents, I am understandably
nervous about unknown files lying around on the server.  If anyone
knows how these files are created and, most important, how I can keep
them off, please let me know.  Many thanks.

   Robin Russell///Oberlin College Computing Center///prussell@oberlin

------------------------------

Date: Wed, 15 Feb 89 15:19:45 est
From: ubu![e-mail]
Subject: Another Anonymous FTP host for VIRUS-L archives

Thanks to Vijay Subramaniam, we now have another anonymous FTP host
for the VIRUS-L archives, lll-winken.llnl.gov.  The difference between
that site and ibm1.cc.lehigh.edu is that lll-winken.llnl.gov is a UNIX
based machine that is connected to the NSFNET backbone, thus providing
fast reliable FTP service to Internet users.  Also, binary files will
be stored there as binary files, not in uuencoded format, and the
VIRUS-L digests will be stored individually (by number), not in weekly
logs.  Finally, all the files will be stored hierarchically in
subdirectories.  The directories are as follows:

virus-l - base directory for VIRUS-L related files
virus-l/archives - base directory for archive files
virus-l/archives/1988
virus-l/archives/1989
...                   - each subdir contains digests for that year.
virus-l/src - base directory for programs
virus-l/src/pc
virus-l/src/mac
virus-l/src/misc
...                   - each subdir contains programs for indicated machine.
virus-l/docs - directory for virus related documents, like the
               Internet Worm reports.

It will take a few days to get all the files there, so please be
patient.  Comments, suggestions, etc., are welcomed.

Ken

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest              Friday, 17 Feb 1989         Volume 2 : Issue 50

Today's Topics:
INIT29 in documents (was: AppleShare network security) (Mac)
virus book
Hardware-induced virus reported in Communications of the ACM
ANTI virus report (Mac)
Closed virus list proposal

---------------------------------------------------------------------------

Date:     Thu, 16 Feb 89 16:12 GMT
From:     Danny Schwendener <[e-mail]>
Subject:  INIT29 in documents (was: AppleShare network security) (Mac)

> [...] Since there is now a
> virus (INIT 29) that attaches itself to documents, I am understandably
> nervous about unknown files lying around on the server.

A copy of the INIT29 virus in a 'plain' document (i.e. with a file type
different to 'INIT','CDEV' or 'RDEV') will not be executed. It just
uses up unwanted space. Still, that PageMaker could break the network
security of Appleshare is rather odd.

- -- Danny Schwendener
   ETH Macintosh Support

------------------------------

Date:     Thu, 16 Feb 89 13:21 EST
From:     <[e-mail]>
Subject:  virus book

I ordered the virus book "viruses/high tech risk.." from abacus
$18.95+ship.. 4 day delivery.  It looks interesting.  I will read it
over the weekend and send a description monday.

James Peterson, sys engineering LIU/South
[e-mail]
516/283-4000 x351

------------------------------

Date:     Thu, 16 Feb 89 16:50 EDT
From:     <[e-mail]>
Subject:  Hardware-induced virus reported in Communications of the ACM

>From Communication of the ACM, February 1989, Volume 32 Number 2, Page 274

        Nova University and ErrorNot Isolate Particular Computer Virus

        A hardware-induced computer virus could potentially affect 25
million microcomputers, according to a recent discovery by researchers
at Nova University and ErrorNot Corporation.
        The researchers say the virus is the result of faulty
programming in the microcode of a device used in computers.  Research
indicates this virus causes data corruption, and its random pattern of
attack with small data destruction makes it difficult to identify.
The virus's dormancy period varies from weeks or months to even years.
        Nova University's Computer Science Department has assembled
the results of its findings (TR-881101-1) and a risk-assessment
program that helps users determine their susceptibility to the virus.
Both are available on a disk for $5 from Dr. Edward R. Simco, Dean,
Computer Science Department, 3301 College Avenue, Fort Lauderdale, FL
33314; [phone].
        The researchers at ErrorNot Corporation have created a
slotless device they say is effective in eliminating the virus.  For
more information contact William R. Griffin, President, ErrorNot
Corporation, 3200 North Federal Highway, Suite 120, Boca Raton, FL
33431; [phone].

        Anyone heard about this from any other source?  Anyone at Nova
University or ErrorNot who would like to elaborate?  Cheers...

                                Mark James Burge
                                mjburge@owucomcn

------------------------------

Date:         Fri, 17 Feb 89 02:42:00 +0100
Sender:       Virus Alert List <[e-mail]>
From:         Danny Schwendener IDA <[e-mail]>
Subject:      ANTI virus report (Mac)

This is a report on the ANTI Virus. For any information, please contact
me directly at the following address:

Danny Schwendener
ETH Macintosh Support, ETH-Zentrum, m/s PL, CH-8092 Zuerich, Switzerland
UUCP:     [e-mail]     BITNET:    [e-mail]
Internet: [e-mail]   AppleLink: macman%czheth5a.BITNET@DASNET#


Note: This is an extract of the full report. Sensitive information has
      been removed. The full report has been sent to known authors of
      virus detectors and vaccines. Please distribute this version of
      the report as widely as possible. I don't have access to CompuServe,
      GEnie or CalvaCom.


A. HISTORY

The virus initially appeared in France. So far, it has been signaled
in Paris, Marseille and a few other places in France. Thierry
Lalettre, chief moderator of the Macintosh forum in CalvaCom, alerted
by user contributions in his forum, posted a warning to CompuServe and
mailed samples of the virus to a few authors of macintosh vaccines and
viral detectors, including myself.

Note: CalvaCom (formerly Calvados) is Europe's largest commercial
      electronic conferencing system, in the same spirit as CompuServe
      or GEnie, but mainly directed at owners of Apple products.



B. OVERVIEW

The ANTI Virus is a program that attaches itself to the end of the
main code resource of an application. It patches the main code so that
it is invoked in the first place each time the application is started.
An infected application will try to infect the system heap, if it
wasn't already infected beforehand (the system heap means the part of
the system that has been loaded into memory at boot-time. ANTI does
*not* infect the file 'System').

The virus does nothing hazardous besides propagating itself. It is
less contagious than the INIT29 virus, but more than nVIR.

The hypothesis made by Thierry Lalettre, stating that Apple France
Developer Support Manager Alain Andrieux' program 'Stamp 1.0b5' has
been purposely recompiled by an unknown person to include special
infection code, is wrong. A disassembly of all resources in the
application only showed up that it was infected in a normal way by the
ANTI virus.

Thierry also stated that the virus only attacks applications with CODE
ID=1 named "Main". This is not correct. Actually, the virus propagates
to all applications whose main code entry starts with a JSR. Most
compilers create this type of applications, and some of them,
including MPW, name the CODE ID=1 resource "Main".  Under certain
circumstances, the virus also propagates to all other kind of
applications (i.e. the ones which don't start with a JSR).

The virus assumes that the main program entry of the application to
infect is contained in CODE ID=1. This is the case in all normal
applications. Applications whose main routine is contained in a CODE
resource different from ID=1 will either not be infected or crash.

Portions of the code suggest that the virus has been written as part
of a copy-protection scheme.



C. DETECTION

<some stuff removed>

The virus can be detected by several means:

- - it adds 1344 bytes to the CODE ID=1 resource of the file. An infected
  application will have grown by 1K. The modification date is changed to
  the date and time of the infection.

- - it contains seven occurrences of the hex sequence $16252553. The last
  occurrence of this sequence is located 43 bytes before the end of the
  CODE ID=1 resource. The virus uses this sequence to detect if a System
  or an application has already been infected.

- - the virus also contains a 9-char. pascal string 'ANTI ' (hence its name)
  followed by the hex sequence. The 9-byte string is followed by the
  pascal string '#000000'.

- - it patches _MountVol and _OpenResFile.

Trap watcher programs like GateKeeper, RWatcher or Vaccine will
successfully prevent infections. There is however a restriction with
Vaccine: As the virus temporarily uses the pointer to the global
variables (A5) for internal tasks, Vaccine will not be able to access
the screen to display a warning alert. If the option "Always compile
MPW INITs" is unchecked, it will beep and wait that the user presses
'y' (allow resource copy) or 'n' (don't allow copy). If the option is
checked, Vaccine will allow the infection without warning the user. So
be careful if you use that option.

The next release of VirusDetective will be able to find this kind of
virus by looking for specific hex sequences.


D. REPAIR

Note: I personnally don't endorse this. Badly repaired applications
      may cause much more harm than the virus itself could ever do.
      An infected application should be deleted. I'm including this
      information for those who forgot to backup their disks.

The virus starts with the following hex sequence:

  000000: 6000 0028 0000 0000 1625 2553 0723 3030
  000010: 3030 3031 0941 4e54 4920 1625 2553 0723
  000020: 3030 3030 3030 xxxx xxxx

xxxx xxxx contains the saved values for the instruction words that
have been patched by the virus.

To repair an application:

1- Be sure you're working in a clean environment (uninfected Finder
   and ResEdit).

2- Open the CODE ID=0 resource. Write down the word at position 16
   (first word of the third line if opened with ResEdit). This value
   tells you at what position within the CODE ID=1 resource you have
   to look for the patch, and is usually $0000.

3- Search in the CODE ID=1 resource for the hex sequence I described
   above. write down the value I noted as 'xxxx xxxx'.

4- Still in CODE ID=1, find the location of the patch, with the value
   you found in step 2. The first word of the patch should be $4EBA.

5- Replace the patch by the two words you found in step 3.

6- Remove the whole virus code (everything from the virus start to
   the end of the resource). This step is not absolutely necessary.



D. INTERNAL WORKINGS

<lots of text deleted>

The _MountVol patch works as follows:

- - Call original _MountVol

- - Check if mounted volume is a floppy drive. If not, exit.

- - Check if floppy is old (400K) or new (800K) and if the disk is
  single-sided or a double-sided. According to the result, read in either
  logical block 192 or 384.

- - check for our hex sequence in position 8 of the block. If found, JSR
  to the code in position 0 of the sector, then exit.

Note: The virus does not contain any portion of code that writes something
      directly to a logical block. Also, the code that will be executed
      if the search is successful is not known at this point. This routine
      has a strong ressemblance to existing copy-protection schemes. It
      is very possible that the virus is part of a copy-protection. I
      won't comment on copy-protection per se, but I find using viruses as
      part of a product's protection scheme extremely unethical.

------------------------------

From:       David.J.Ferbrache <[e-mail]>
Date:       Fri, 17 Feb 89 10:32:13 GMT
Subject:    Closed virus list proposal

             A proposal for a closed virus technical list
             --------------------------------------------

Following my original message concerning authentication, I have a
proposal which I wish comments on, namely the formation of a new virus
list (in addition to VIRUS-L) with a closed membership.

As you may be aware the issue of viruses is, and is likely to remain,
exceptionally sensitive. Subscribers to VIRUS-L who are industrial or
commercial concerns are naturally extremely reticent to disclose any
details of infections on open lists, equally researchers in the field
are loath to circulate any technical details over and above those
concerning the symptoms of the virus, and the disinfection methods.

I my case I am researching the area of viruses, attempting to analyse
the techniques of concealment utilised by viruses with a view to
the analysis of future trends in the threat from viruses, and to
develop possible counters to virus infection. Such work requires a
degree of technical information which many people will not reveal
on an open list, nor will they mail such information to a correspondant
on the list without authentication.

Therefore (and I have discussed this informally with Ken) I would like
to propose:

1. The establishment of a closed additional virus list
   with membership by invitation initially, followed by additions only
   on request with suitable authentication. (Checks with establishment,
   through known contacts etc)

2. That the materials discussed on the closed list are monitored by a
   moderator who would be responsible for circulating any non-sensitive
   material to VIRUS-L and VALERT-L. Eg, initial contact reports to
   VALERT-L, symptoms and information on disinfection software to VIRUS-L.

3. That VIRUS-L remain an open list for discussion on all aspects of viruses
   (hopefully people will realize that reports of new viruses must still be
   public and contain sufficient details to identify the virus, and take
   elementary precautions).

Finally regarding the security of the new list, I suspect that we can take
one of two approaches,

1. Handle traffic in an unencrypted manner and assume the possibility
   of interception on route either by intermediate uucp sites or by
   ethernet taps.

2. Encypt end-to-end with the obvious handling and key management
   difficulties.

I think everyone who subscribes to this list should realize that the
threat from computer viruses is likely to grow rapidly, as will the
difficulties of monitoring the spread of new strains and the
development of disinfection software. This is an area where a world
wide list such as that proposed can make a major contribution in
acting as a clearing house for virus information.

It is vital however that the members of such a list trust both the
integrity of the list and of the members (who would preferably be
either academic researchers in the field, or representatives of
companies or known consortia).

Comments please, either to the VIRUS-L discussion list or by email to me
personally. I will collate the comments and discuss the outcome with Ken,
and then mail the list concerning whether the formation of the new list
will go ahead.

Dave Ferbrache                            Personal mail to:
Dept of computer science                  Internet <[e-mail]>
Heriot-Watt University                    Janet    <[e-mail]>
79 Grassmarket                            UUCP     ..!mcvax!hwcs!davidf
Edinburgh,UK. EH1 2HJ                     Tel      (UK) 031-225-6465 ext 553

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest              Sunday, 19 Feb 1989         Volume 2 : Issue 51

Today's Topics:
MIT's report on the Internet worm (11/88) available
Mac INIT 10 - a problem?
New anti-virus group: CoTRA
Flu_Shot 1.51 now available

---------------------------------------------------------------------------

Date: 17 Feb 89 10:00:00 EDT
From: "HILL" <[e-mail]>
Subject: MIT's report on the Internet worm (11/88) available

The MIT report on last November's Internet worm is available for
anonymous FTP from pine.circa.ufl.edu (128.227.128.55).  If you are on
SURANET this will probably be faster than other sites.

Les
CIRCA, University of Florida
Internet:       [e-mail]
BITNET:         vishnu@ufpine

[Ed. Thanks, these files are also available on lll-winken.llnl.gov.]

------------------------------

Date:    Fri, 17 Feb 89  17:31:54 EST
From:    [e-mail]
Subject: Mac INIT 10 - a problem?

I'm forwarding this for someone who doesn't subscribe to the list:

Please reply directly to him at:
 [e-mail]  / [e-mail]


- --- Forwarded Message Follows:


Virus Rx is picking up INIT 10s.  It says that there is "no known
problem", and most of these are INITs (superclock among others).

Is this a problem?  Should I worry?

Stephan Cavarra, [e-mail] / [e-mail]

- --- End Included Message.

------------------------------

Date:       18-FEB-1989 15:23:40 GMT
From:       [e-mail]
Subject:    New anti-virus group: CoTRA

The latest issue of New Scientist (Vol 121, No 1652) contains a news
article entitled 'Virus vigilantes' reporting on the formation of a
new group of software companies and users, called the Computer Threat
Research Association (CoTRA). This group intends to "research,
analyse, publicise and find solutions to threats to the integrity and
reliability of computer systems".

The group is to be based initially in Britain, but hopes to build
links with Europe and the rest of the world.

Can anybody out there expand on this?

- -- Jason --

+------------------------------------------------------------------------+
| Jason Brown  JANET           : [e-mail]                |
|              Internet/ARPAnet: [e-mail]|
|              BITNET/EARN     : [e-mail]                |
+------------------------------------------------------------------------+

------------------------------

Date:     Sun, 19 Feb 89 14:57 EST
From:     <[e-mail]>
Subject:  Flu_Shot 1.51 now available

Flu_Shot + ver 1.51 is now available from RAMNET BBS. I got my copy in
the mail because I was a registered user of FSP+ 1.4.

FSP+ v1.51 (and v1.5) doesn't do the CMOS check any more hence that
sometimes annoying message "CMOS has changed" doesn't pop up from time
to time. It also has a -W command line option which prevents it from
triggering every time a file is opened with write access. It still
protects files from being written to however! According to the update
posted int the FSP_151 archive some *NASTY* bugs in v 1.4 and earlier
have been fixed, so v1.4 users please take note.

I also tested v1.51 for the"print.com-TSR" problem reported in an
earlier issue of this digest. As long as you register print.com as a
TSR with the T option in the FSP.DAT file, FSP+ 1.51 *DOES NOT* flag
print.com as an UNAUTHORIZED TSR.  (I think the message was referring
to v 1.5 which I have *NOT* tested. Also, print.com does TSR after it
has initially been loaded into memory)

Mathew Mathai           |  I don't work for RAMNET or Ross Greenberg ...
BITNET: MATHAIMT@VTCC1  |  but I whole heartedly support his efforts
                        |  to rid this world of virus writing SLIME !

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest             Tuesday, 21 Feb 1989         Volume 2 : Issue 52

Today's Topics:
Flu_Shot availability (PC)
nVIR virus on Mac SE
Re trusted trojan horse mail
nVIR virus and suggested remedies (Mac)

---------------------------------------------------------------------------

Date: Sun Feb 19 23:07:53 1989
From: utoday![e-mail]
Subject: Flu_Shot availability (PC)

To:  Matthew Mathai and other FLU_SHOT+ users:

Be advised that I'm now available on the below address and can answer
any questions regarding the FLU_SHOT+ series of programs.

Ross M. Greenberg
UNIX TODAY!             594 Third Avenue   New York   New York  10016
Review Editor           Voice:(212)-889-6431  BBS:(212)-889-6438
uunet!utoday!greenber   BIX: greenber  MCI: greenber   PCMagNet: 72241,36

------------------------------

Date:     Mon, 20 Feb 89 13:44 EST
From:     STEVEN LINDELL <[e-mail]>
Subject:  nVIR virus on Mac SE

I have a virus on my Mac SE which installs itself as resource "nVIR"
in applications. It does not appear to damage documents, and appears
to be unable to get through locked files.  It does damage those
applications it enters, but not all of them (Resedit OK) others work
erratically for a while and then won't launch. Telltale signs were
modification dates on applications just after they launch.

If any one knows of this virus, please let me know what would be the
best way to eradicate it.

P.S. It also modifies some system files possibly (Macromaker, System)?

------------------------------

Date: Mon, 20 Feb 89 16:07:27 est
From: [e-mail] (James Ellis)
Subject: Re trusted trojan horse mail

As others have pointed out, many terminals do support sendline and
sendpage functions and although some mailers block escape characters,
not all do.  This is also a problem with finger, which can be done
remotely, and with systems that do not provide adequate protection for
user's /dev/tty* devices (still the case on many unix systems).
Unless you know that your terminal or emulator does not support such
"features", beware.

A common "fix" proposed is to simply not trust mail from someone you
don't know.  But the problem is that such "worm" mail (it is really
more a worm than a virus) *does* come from someone you know.  Since it
is "you" (or commands from your terminal) causing letters to be
propogated, the mail looks like it is coming from you.  The IBM
"Christmas Tree Virus" used the victim's personal mail list for more
targets with a resutling high probability of mail coming from someone
whom the next user "trusted".

This is the same problem as with a biological epidemic, of course,
until the public becomes aware of it.

                                James Ellis

------------------------------

Date:     Mon, 20 Feb 89 23:12 EST
From:     <[e-mail]>
Subject:  nVIR virus and suggested remedies (Mac)

We here at calm, quiet, Quakerly Haverford have just discovered the
nVIR virus on almost all of our Macs.  As I am relatively new to this
list (and incredibly anxious to restore calm and quiet to our campus),
I was wondering if any of you might be able to offer any suggestions
as to the best strategy for dealing with the nVIR strain.  We have so
far used Interferon 3.0 to identify affected files, although
Interferon seems to choke on AppleShare volumes (we have two
AppleShare servers which were hit pretty badly).  Would Vaccine or Rx
work any better?  Does anyone have any general info. they could share
regarding the general characteristics of the nVIR virus?  It would be
nice to know the nature of the beast with which we deal.  I would also
be VERY interested in how other colleges/universities dealt with the
cleaning of students' disks so as to prevent reinfection of the public
machines.  Thanks in advance for any help you might be able to
provide.

Eric Davies
Academic Computing Consultant
Haverford College
Haverford, PA 19041

[e-mail]
[phone]

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest            Wednesday, 22 Feb 1989        Volume 2 : Issue 53

[Ed. My apologies for taking so long to get this digest out - we were
having some mailer problems.]

Today's Topics:
Re: Viruses
Abacus book
Closed virus list proposal
Re: Who *benefits* from viruses?
Student's Disks (MAC)

---------------------------------------------------------------------------

Date:         Wed, 1 Feb 89 10:40:35 EST
Sender:       SECURITY Digest <[e-mail]>
From:         Alex Nishri <[e-mail]>
Subject:      Re: Viruses

Three copies of a garden variety nVir were included on the "QLTech
MEGA-ROM" CD-ROM, Volume 1 October 1988, produced by Quantum Leap
Technologies, Inc.  This CD-ROM is a collection of public domain and
shareware Macintosh software, available for about $35.  Quantum Leap
Technologies sent a letter out once the virus was discovered, and
subsequently released a replacement disc, labelled Volume 2 December
1988.  Unfortunately for us here at the University of Toronto
Computing Services, the virus had already spread by that point.  We
know the virus has spread into our University Community, but have no
way of estimating how many people were affected.  Within the Computing
Services itself about twenty machines were hit.

------------------------------

Date: Tue, 21 Feb 89 15:52:05 est
From: ubu![e-mail]
Subject: Abacus book


In briefly looking over the Abacus book, Computer Viruses: A High Tech
Disease, I see that the book is fairly interesting, but (imho) much
seems to have been lost in the translation from German into English.
In English, the book appears to be a fairly random scattering of
information on viruses, including the infamous source code examples.
Even so, it's worthwhile reading; Mr. Burger (the author) has some
interesting things to say, and his examples are worth keeping a copy
of.

I would be interested to see whether the publishing of these examples
has any real effect on computer virus activity.  As people become more
aware of the virus threat and take suitable precautions, I should
think that any virus author would have to be more clever than to use
an existing example if s/he has any expectations of his/her creation
spreading any significant amount.  Perhaps this is an overly
idealistic attitude.

It is interesting to note that Mr. Burger didn't include the source
code for all of his examples.  Specifically, when discussing the VIRDEM
virus demo program which has been available since the Chaos Computer
Congress in December 1986, he says, "Unfortunately the source code
cannot be published because with the help of the source code anyone
would be able to change the manipulation task and have a
non-overwriting virus in 8088 assembly language."  Ironically, he goes
on to give several 8088 assembly language examples.

Ken

------------------------------

Date: Tue, 21 Feb 89 15:01:09 MST
From: Chris McDonald  ASQNC-TWS-R 678-4176 <[e-mail]>
Subject: Closed virus list proposal

David,

I would like to contribute these thoughts to your proposal.  First,
there is a large range of government users who subscribe to Virus-L
who are outside the commercial and industrial concerns identified in
your proposal.  These "government" subscribers may not be academic
researchers, but could be certified to meet whatever "trust" criteria
might be important.  This assumes that "trust" can somehow be
established by "suitable authentication" and that authentication and
trust are somehow related in the first place.

Second, the real value of Virus-L and VALERT-L lies in their ability
to disseminate information quickly and with a rather high degree of
reliability and integrity.  I wonder if the establishment of yet
another list will not result in the eventual demise of these lists
because individuals will choose to post only "non-sensitive"
information to these lists; while reserving the "sensitive" material
for your proposed addition.  This assumes one can define sensitive to
everyone's satisfaction.

Third, one has seen rather detailed information posted to the INTERNET
on specific viruses, their symptoms, their strengths, their
weaknesses, and finally their eradication.  Whether such discussion
has led the authors of viruses to modify their product or to
specifically combat the countermeasures is admittedly a difficult
question to answer.  But, if such information had not been readily
available, most of us without the current Virus-L mailing would have
had to suffer through an infection with little background on control
strategies or on detection and recovery techniques.  The fact that
"sensitive" information is available on Virus-L, RISKS-FORUM and other
mailings is a reality which I think benefits all of us.  The issue of
network encryption and host/user authentication are real problems.
But, if one waits until those problems have cost-effective solutions,
we will have assisted the virus authors in my opinion.  I do not wish
to engage in a debate over what is "sensitive" or not, but I note this
fact.  Both Gene Spafford and MIT have distributed reports on the
recent INTERNET Worm.  Those analyses identify technical
vulnerabilities which typically have been reserved for a small circle
of system administrators and WIZARDS.  But most of us on the INTERNET
are not in that circle, nor are we WIZARDS.  I applaud the subject
reports precisely because they represent a conscious attempt to
distribute information.  I think an additional list, which would have
to rely on a moderator to extract material for posting elsewhere,
would have the opposite effect and would impede distribution.

Four, I think we in the US are already as a matter of Federal statute
and executive policy equipped to support the collection and
distribution of that really "sensitive" data to which you refer.  The
National Security Agency and the National Computer Security Center
already provide support to the government, university and private
sectors.  The National Institute of Science and Technology has the
charter to provide comparable support to the government, university
and private sectors in the area of unclassified computer processing.
I have no reason to question either the competency or the sincerity of
those individuals tasked with such responsibilities.  In fact, I have
always been impressed with their professionalism.

Finally, I really like the idea of a "clearing house" on virus
information.  I think we already have the foundation in Virus-L and in
the general effort of Ken and others at Lehigh.  I really think it is
too difficult a task to determine the criteria of "trust" and to then
implement and maintain the administrative tasks associated with that
criteria.  Therefore, I would prefer to defer the establishment of an
additional list at this time.

Thanks for the opportunity to express my thoughts,

Chris McDonald
White Sands Missile Range

------------------------------

Date:         Fri, 3 Feb 89 00:21:46 MST
Sender:       SECURITY Digest <[e-mail]>
From:         Lazlo Nibble <[e-mail]>
Subject:      Re: Who *benefits* from viruses?

>From SECURITY Digest...........

- ----------------------------Original message----------------------------
> So, some kind person comes along and starts to distribute a virus.
> This makes everyone SO SCARED of accepting a non shrink-wrapped diskette
> that the piracy problem just goes away ...

It's already happened, at least in the Apple pirate community.  Last
summer, CyberAIDS and Festering Hate, two Apple //-specific viruses,
were released into the pirate community.  They were real killers, and
Festering Hate is apparently still floating around in some quarters.
But even though the pirate community was hit (and hit HARD -- several
of the largest pirate BBSes in the country were knocked down before
anyone even knew what was happening) things are still trundling
happily along today.

There are no simple solutions to software piracy.  All the ones I've
heard that sounded to me like they might work involved measures so
draconian that only the most singleminded anti-pirate types would
consider them feasable.  Nothing short of a complete reprogramming of
society's views on WHO OWNS INFORMATION is going to put an end to it,
and frankly I don't see that happening in my lifetime . . .

laz ([e-mail])

------------------------------

Date:         Wed, 22 Feb 89 10:02:02 EDT
From:         "A. Goldberg" <[e-mail]>
Subject:      Student's Disks (MAC)

At The University of Kentucky, although we have very few Mac's, and
they are exclusively in one room (so this may or may not be applicable
to E_DAVIES@HVRFORD), before disks are allowed to be used they must be
checked by a consultant to be virus-free.

Last spring aparently (I was not here at the time) we ran into a
similar problem.

However, there are a number of Mac's on campus that are not available
to general student use, and as a result many of those users don't
realize that virus's even exist -- which obviously leads to a lot of
virus's floating around campus...but the machines available for
general use are virus-free.

Hope this helped E_DAVIES (and others)

Adam Goldberg - [e-mail]

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest            Wednesday, 22 Feb 1989        Volume 2 : Issue 54

Today's Topics:
Macintosh Viruses
Dealing with nVIR on a large scale (Mac)
Disk Washing -- or -- Sanitation in our Public Microlab (Mac)
Public Mac facilities at Cornell
Re: Interferon vs. AppleShare (Mac)

---------------------------------------------------------------------------

Date: Wed, 22 Feb 89 13:18 EST
From: [e-mail]
Subject: Macintosh Viruses

Hello,
   My name is Ed and I work for Rutgers University (NJ).  We have been
hit with a few different Mac viruses in the past and have become
unfortunately well acquainted with them.  In fact, a very significant
number of students who own disks still have viruses on them.  One
virus we have come across is nVIR.  A few different "strains" have
actually appeared.  The best known remedy for this virus that I have
found is ANTI-PAN.  There are also remedies for the scores virus
(which we were also hit with).  But is there a remedy for the ANTI
virus?  We haven't been hit with it, but it might be safer to be
prepared.  Thanks.  Ed,
                                  IN%"[e-mail]"

------------------------------

Date:    Wed, 22 Feb 89 13:48 EST
From:    "Christopher Tate" <[e-mail]>
Subject: Dealing with nVIR on a large scale (Mac)

Here at Penn State there are some general guidelines we use to avoid
massive infestations of viruses.  These rules were adopted after a
major epidemic of both nVIR and Scores last semester.

First, all of the software available for student use is kept on remote
servers (AppleShare), which the individual machines (Mac SE's) link to
via AppleTalk.  The servers are READ-ONLY, to prevent the applications
from becoming infected through the network.

Second, the lab operators check each network startup disk for viruses
when it is returned (this is done with Virus Detective).  If a disk is
infected, it is recopied from a permanently locked master disk.  This
recopying is done with Copy II Mac, and is a complete rewrite of the
disk.  This may not be totally necessary, but is a fairly fast and
absolutely secure method of restoring a damaged startup disk.

Note that no attempt is made to "repair" damaged startup disks.  It is
much easier and faster to simply recopy them.  If, however, a user
turns in an infected startup disk, then the operator can offer to
check the user's own disks for viruses.  Often the user's disks are
also infected.  In this case, the operator (or one of the operator's
friends who is familiar with the correct procedures) can use programs
such as KillScores, Ferret, Vaccination, etc. to "disinfect" the
user's disks.

This procedure works fairly well, but once a virus appears on campus
it will probably remain a lingering problem.  The only to keep the
incidence of infection down is to be diligent in checking the
public-use disks EVERY TIME THEY ARE USED.  If two operators working
two consecutive shifts here neglect to check for viruses, the
percentage of network startup disks that are infected more than
doubles.

- -------
Christopher Tate                           | Mercy (noun):
  Internet: [e-mail]           |  The infrequent art of turning
  Bitnet: cxt105@psuvm                     |  thumbs-up on your opponent at
  Uucp:   ...!psuvax1!psuvm.bitnet!cxt105  |  the end of your rapier.

------------------------------

Date:     Wed, 22 Feb 89 12:06:46 PLT
From:     Joshua Yeidel <[e-mail]>
Subject:  Disk Washing -- or -- Sanitation in our Public Microlab (Mac)

We have a Microcomputer Lab which is used for "open-access" when it is
not reserved for classes.  Last November we discovered that it was a
sink of infection for the Scores virus.  The situation was
particularly serious because we were recommending that everyone use
our "MicroLab Laser Startup" disks so that everyone on the AppleTalk
network had the same LaserWriter driver (avoiding many restarts of the
LW).  People routinely used their applications with our systems, so
infection could readily spread from their app disk to our system disk,
then from our system to the next user's app disk, and so on.

As a result, we have now adopted what I call "disk washing" as a
policy and procedure.  We have clean backups for each disk which we
hand out to users.  When we get the disk back from the user, we "wash"
it by doing a sector copy from the backup.  No disk is recirculated
until it has been washed.  (Same rule as in a restaurant, *mutatis
mutandis*). In practice, we have a "dirty disks" box in which disks
pile up until a slack time, when the monitor goes through and recopies
from backups).

So far, we have not seen any re-infection (we check regularly).  I am
not qualified to way that there could NEVER be a virus which could
defeat this disk-washing approach, but no Mac virus yet described in
the literature (VIRUS-L) can do it.

I don't know how this would apply to AppleShare volumes.  I also don't
know how one would manage hard-disk equipped public micros.  I am
recommending that, when we ourgrow diskettes, we use removable hard
disks (Syquest), "big" floppies (Jasmine), or some other technology
which will permit "washing" between uses.

------------------------------

Date: Wed, 22 Feb 89 15:18 EST
From: "Mark H. Anbinder" <[e-mail]>
Subject: Public Mac facilities at Cornell

The public Macintosh facilities at Cornell have antivirus procedures
that seem to be working fine here.  Each of the several facilities has
one Mac set aside for users to check their disks for viruses.  These
Macs are equipped with a software-locked hard disk on which resides
Vaccine, Interferon, and various other programs for finding and
removing viruses.  Many of the users are using these machines to check
their disks... some don't take the time, but that's to be expected.

Also, since our public facilities have copies of various software
products on disk to lend out, these disks must be handled very
carefully.  The policy that was implemented a couple of months ago is
that ALL of these disks, when they are returned to the facility's
operator, are initialized, and restored from locked originals.  This
entirely eliminates the possibility that users are infecting the
public disks (but it assumes, of course, that the originals are not
infected...  this is, obviously, very important!).

All of the facilities have signs up that tell users to turn off the
machines when they're done.  The signs also say that, if a machine is
found still on, it should be turned off and back on before it's used.

These measures seem to have done a good job of slowing the spread of
viruses at Cornell, which HAS been hit by several viruses.  I'd be
interested to hear some descriptions of the measures being taken at
public facilities at the institutions of our other subscribers.

Mark H. Anbinder
Dept. of Media Services
Cornell University

------------------------------

Date:         Wed, 22 Feb 1989 11:00 -
From:         Peter W. Day <[e-mail]>
Subject:      Re: Interferon vs. AppleShare (Mac)

RE Eric Davies statement that Interferon 3.0 chokes on AppleShare
volumes, I wonder if it only has problems when running against the
volume from an AppleShare client.  If the AppleShare server is a Mac,
he should be able to take down the server and run it on the server
directly as a standalone micro.

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest              Friday, 24 Feb 1989         Volume 2 : Issue 55

Today's Topics:
Message resend request
Re: another nVIR (Mac)
RE: Disk Washing -- or -- Sanitation in our Public Microlab
Macintosh Virus Relief...
Info wanted,  I know you can do it, what a great bunch o' guys!

---------------------------------------------------------------------------

Date:     Wed, 22 Feb 89 18:01 EST
From:     <[e-mail]>
Subject:  Message resend request

Due to a quota crunch I had to delete all my mail, both old and new.
Would the person(s) from Sweden who asked me (personally) about public
domain anti-virals please re-send their message, I think yours was one
of the ones that got zapped.

Thanks,
Steve
- -------------------
Steve Okay [e-mail]/[e-mail]/CSR032 on The Source

                        "Join today!!, free introductory offer to new
                        members! Its the `Beam Weseley Crusher into a
                        Bulkhead Society' "

------------------------------

Date:         Thu, 23 Feb 89 17:32:17 EST
From:         Joe McMahon <[e-mail]>
Subject:      Re: another nVIR (Mac)

Vaccine will protect you from nVIR infections. Installing a dummy nVIR
ID=10 in the System file will stop nVIR from spreading into a clean
system (but the system will show up as infected with most detectors).

nVIR follows the two-stage infection technique - an infected
application installs the viral resources into the system. When the
system is rebooted, every application run under that system gets
infected.

There are two different "strains" of nVIR, only slightly different
from each other. Most of the detectors can find both. There is also a
variant called "Hpat" (it has "Hpat" resources instead of "nVIR"
ones).

nVIR actually modifies the subject application. It is recommended that
a detector such as Virus Rx or Interferon be used to find the infected
files, and that these be replaced from locked, known-clean originals.

Disinfectors are available for a "quick fix", but Apple (and I)
recommend replacement.

 --- Joe M.

------------------------------

Date:         Thu, 23 Feb 89 15:47:32 PLT
From:         Joshua Yeidel <[e-mail]>
Subject:      RE: Disk Washing -- or -- Sanitation in our Public Microlab

As you have no doubt seen in VIRUS-L, lots of people are using
checking programs in public labs (at Cornell, they reserve a whole Mac
so that users can check their disks!).  We did not feel that this
approach would give us sufficient protection against new viruses which
were not yet known to the detectors.  Disk washing, though somewhat
tedious, is quite a bit more secure.  Each site, of course, will have
to balance cost against risk for itself.

------------------------------

Date:     Thu, 23 Feb 89 20:32:03 PST
From:     CMDR@CALSTATE  (Cmdr Spock)
Subject:  Macintosh Virus Relief...

For those of you who have caught the conversations midstream of any
Macintosh discussion regarding viruses, there are two programs
(copyrighted) that claim that they can eliminate all or most Macintosh
viruses, not to mention, repair any damaged applications.

One that I own and haved tested thoroughly is "Virex", sold by HJC
Software.  They currently offer relief for ALL *KNOWN* Macintosh
viruses including the recently introduced "ANTI" virus.  Current
release is 1.3 and can be purchased at most Apple retail stores that
offer any of Apple's products.  Price is around $40.  Support is good
and they update you for a small fee.  They offer to repair any damaged
application including the Finder, System, and Desktop files.

Hopes this helps those who would like to be rid of nVIR Type B.

Robert S. Radvanovsky          [e-mail]
California Polytechnic Univ.   [e-mail]
Pomona, California

P.S.  We ourselves were panicked by a campus-wide epidemic of nVIR Type B.
      Thanks to "Virex", the problem no longer exists.

------------------------------

Date:     Fri, 24 Feb 89 12:53:58 GMT
From:     [e-mail]
Subject:  Info wanted,  I know you can do it, what a great bunch o' guys!

Hi Folks!

      I bet this has come up so many times, that you are bored stiff
hearing about it.  I am doing a presentation about viruses etc and I
want to make sure I have my facts straight.

Definitions:

Trojan Horse: A program which performs a function (e.g. Game) and
              deposits something nasty somewhere on (say) a hard disk
              to really screw things up.

Worm :        A program that is designed to copy itself and replicate all
              over the place and generally slow systems down, they can
              have nasty features too (e.g. deleting files etc).  The
              Christmas card thingy was a worm.

Virus :       This is something that can 'infect' a disc.  Some code lurks
              somewhere and puts itself on discs that is used on the
              machine.  These discs can in turn infect other machines
              and at some time, random, or time bomb, do something
              nasty.

This is how I see these things at the moment.  I would like some
confirmation about this lot.  Are there any others?  I am not really
interested in machine specific nasties.  What are these things that
infect specific programs though?

Any comments/ideas on things like, what can be done about the little
blighters, or what the programmer responsible thinks he gains from it.
Who does gain (if anybody)?

Please reply to me direct.

Many thanks, you are all life savers!

                                   Steve.

                                   JANET:  UA0095@SALF.B
                                   (God knows what you'll have to use,
                                    but I'm confident you'll pull through)

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest              Friday, 24 Feb 1989         Volume 2 : Issue 56

Today's Topics:
Lab procedures

---------------------------------------------------------------------------

Date: Fri, 24 Feb 89 13:22:08 est
From: ubu![e-mail]
Subject: Lab procedures

The recent messages regarding re-formatting microcomputer lab disks
made me wonder what other sites are doing in their micro labs to
protect themselves.  At Lehigh, we're using Novell Local Area Networks
to act as file servers; the LAN hard disks are read-only (with the
exception of a scratchpad area).  Also, the boot floppies for the LAN
workstations are notchless.  It is interesting to note that the only
labs that got infected by the recent virus (Lehigh Virus version 2,
February 3, 1989) were ones which do not yet have LANs installed.

Ken

P.S. I will be out of town on business on Monday, Tuesday, and
Wednesday of next week, so VIRUS-L will not be distributed for a
while.  Bear in mind that urgent virus *warnings* may be distributed
via VALERT-L during this time.  I apologize for any inconvenience that
this may cause.

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest             Thursday, 2 Mar 1989         Volume 2 : Issue 57

Today's Topics:
Viruses and System Security (a story)
UofU infestation?
Why people write viruses...
FluShot+ 1.51 (PC)
Re: More Info on definitions
Lab Procedures
Re: Closed virus list proposal
Virus psychology information
Flushot+ 1.51 question (PC)

---------------------------------------------------------------------------

Date:         Fri, 3 Feb 89 04:00:00 EST
Sender:       SECURITY Digest <[e-mail]>
From:         AMSTerDamn System <[e-mail]>
Subject:      Viruses and System Security (a story)

[Ed. reprinted from SECURITY Digest]

The following story was posted in news.sysadmin recently.

The more things change, the more they stay the same...

Back in the mid-1970s, several of the system support staff at Motorola
(I believe it was) discovered a relatively simple way to crack system
security on the Xerox CP-V timesharing system (or it may have been
CP-V's predecessor UTS).  Through a simple programming strategy, it was
possible for a user program to trick the system into running a portion
of the program in "master mode" (supervisor state), in which memory
protection does not apply.  The program could then poke a large value
into its "privilege level" byte (normally write-protected) and could
then proceed to bypass all levels of security within the file-management
system, patch the system monitor, and do numerous other interesting
things.  In short, the barn door was wide open.

Motorola quite properly reported this problem to XEROX via an official
"level 1 SIDR" (a bug report with a perceived urgency of "needs to be
fixed yesterday").  Because the text of each SIDR was entered into a
database that could be viewed by quite a number of people, Motorola
followed the approved procedure: they simply reported the problem as
"Security SIDR", and attached all of the necessary documentation,
ways-to-reproduce, etc. separately.

Xerox apparently sat on the problem... they either didn't acknowledge
the severity of the problem, or didn't assign the necessary
operating-system-staff resources to develop and distribute an official
patch.

Time passed (months, as I recall).  The Motorola guys pestered their
Xerox field-support rep, to no avail.  Finally they decided to take
Direct Action, to demonstrate to Xerox management just how easily the
system could be cracked, and just how thoroughly the system security
systems could be subverted.

They dug around through the operating-system listings, and devised a
thoroughly devilish set of patches.  These patches were then
incorporated into a pair of programs called Robin Hood and Friar Tuck.
Robin Hood and Friar Tuck were designed to run as "ghost jobs" (daemons,
in Unix terminology);  they would use the existing loophole to subvert
system security, install the necessary patches, and then keep an eye on
one another's statuses in order to keep the system operator (in effect,
the superuser) from aborting them.

So... one day, the system operator on the main CP-V software-development
system in El Segundo was surprised by a number of unusual phenomena.
These included the following (as I recall... it's been a while since I
heard the story):

- -  Tape drives would rewind and dismount their tapes in the middle of a
   job.

- -  Disk drives would seek back&forth so rapidly that they'd attempt to
   walk across the floor.

- -  The card-punch output device would occasionally start up of itself
   and punch a "lace card" (every hole punched).  These would usually
   jam in the punch.

- -  The console would print snide and insulting messages from Robin Hood
   to Friar Tuck, or vice versa.

- -  The Xerox card reader had two output stackers;  it could be
   instructed to stack into A, stack into B, or stack into A unless a
   card was unreadable, in which case the bad card was placed into
   stacker B.  One of the patches installed by the ghosts added some
   code to the card-reader driver... after reading a card, it would flip
   over to the opposite stacker.  As a result, card decks would divide
   themselves in half when they were read, leaving the operator to
   recollate them manually.

I believe that there were some other effects produced, as well.

Naturally, the operator called in the operating-system developers.  They
found the bandit ghost jobs running, and X'ed them... and were once
again surprised.  When Robin Hood was X'ed, the following sequence of
events took place:

  !X id1

  id1:   Friar Tuck... I am under attack!  Pray save me!  (Robin Hood)
  id1: Off (aborted)

  id2: Fear not, friend Robin!  I shall rout the Sheriff of Nottingham's men!

  id3: Thank you, my good fellow! (Robin)

Each ghost-job would detect the fact that the other had been killed, and
would start a new copy of the recently-slain program within a few
milliseconds.  The only way to kill both ghosts was to kill them
simultaneously (very difficult) or to deliberately crash the system.

Finally, the system programmers did the latter... only to find that the
bandits appeared once again when the system rebooted!  It turned out
that these two programs had patched the boot-time image (the /vmunix
file, in Unix terms) and had added themselves to the list of programs
that were to be started at boot time...

The Robin Hood and Friar Tuck ghosts were finally eradicated when the
system staff rebooted the system from a clean boot-tape and reinstalled
the monitor.  Not long thereafter, Xerox released a patch for this
problem.

I believe that Xerox filed a complaint with Motorola's management about
the merry-prankster actions of the two employees in question.  To the
best of my knowledge, no serious disciplinary action was taken against
either of these guys.

Several years later, both of the perpetrators were hired by Honeywell,
which had purchased the rights to CP-V after Xerox pulled out of the
mainframe business.  Both of them made serious and substantial
contributions to the Honeywell CP-6 operating system development effort.
Robin Hood (Dan Holle) did much of the development of the PL-6
system-programming language compiler; Friar Tuck (John Gabler) was one
of the chief communications-software gurus for several years.  They're
both alive and well, and living in LA (Dan) and Orange County (John).
Both are among the more brilliant people I've had the pleasure of
working with.

Disclaimers: it has been quite a while since I heard the details of how
this all went down, so some of the details above are almost certainly
wrong.  I shared an apartment with John Gabler for several years, and he
was my Best Man when I married back in '86... so I'm somewhat
predisposed to believe his version of the events that occurred.

- --
Dave Platt
  Coherent Thought Inc.  3350 West Bayshore #205  Palo Alto CA 94303

------------------------------

Date:    Sat, 25 Feb 89 00:15 CST
From:    Gordon Meyer <[e-mail]>
Subject: UofU infestation?

I was speaking with my mother tonight and she said that the local news
had a story about a recent virus infestation at the University of
Utah.  She couldn't recall any of the details.  Any VIRUS-L readers
know of this?
- -=->G<-=-
Gordon R. Meyer, Dept of Sociology, Northern Illinois University.
GEnie: GRMEYER  CIS: 72307,1502  Phone: [phone]
Bitnet: tee-kay-zero-gee-are-em-one at enn-eye-you
Disclaimer: Grad students don't need disclaimers!
            I'll have an opinion when I get my degree.
- --- BE YE NOT LOST AMONG PRECEPTS OF ORDER... (book of Uterus) ---

------------------------------

Date: 25 February 1989 14:26:00 CST
From: "Michael J. Steiner  " <[e-mail]>
Subject:  Why people write viruses...

After listening to the VIRUS-L discussion for a few months, it finally
hit me that maybe some people write viruses because... (well, let me
explain it in detail):

The people who write viruses are usually (if not always) people who
are very knowledgeable about computers. Being very knowledgeable about
computers, these people might look down upon novices, and might write
a virus, which would mostly affect novices (who sometimes barely even
know that viruses exist) while not affecting other experts (who are
aware of viruses and know the necessary precautions to avoid
infection). Thus, a virus-writer can get pleasure out of
confusing/disrupting the novices' efforts at learning about computers.
(I hope I explained this clearly enough.)

Any replies, comments, flames, accepted.

Disclaimer #1:  I am an undergrad. :-)         Michael Steiner
Disclaimer #2:  Don't take this note           Email: [e-mail]
                personally.

------------------------------

Date:     Sat, 25 Feb 89 22:19 EDT
From:     Llamas are bigger than frogs <[e-mail]>
Subject:  FluShot+ 1.51 (PC)

I've just downloaded FluShot+ 1.51 from the RAMnet BBS in NYC and I've
noticed that I'm having the same problem with it that I had with
version 1.4......it gives me bad checksums on my command.com,
ibmbio.com and ibmdos.com.  However, all 3 files are okay.  Is it
looking for the "True Blue" versions of these files?  I have a Zenith
z-157 with MS-DOS 3.2.  Has anyone else had this problem?  I glanced
in the manual, there didn't seem to be a way to alter what it's
looking for (hardly suprising...that would be a major hole, in all
likelyhood....).  Any tips/advice would be appreciated.

Paul Coen, Drew University         Bitnet:  PCOEN@DRUNIVAC, PCOEN@DREW

------------------------------

Date:     Mon, 27 Feb 89 09:51:53 GMT
From:     [e-mail]
Subject:  Re: More Info on definitions

Hi there folks, Me again.

Many thanks for the replies to my plea for help about the definitions.
(comments etc are still welcome).  I was suprised to find that out
those who replied, who obviously consider themselves knowledgeable
about the subject, their definitions did all slightly differ.  Below
is a summary of the replies I got, hopefully they are as correct as
the subject will allow (due to it's non-descript nature).  I would
gratefully receive anything that you would like to add.

TROJAN HORSE

A Trojan horse is a program that does something that the programmer
intended it to, but the user did not.  (And, generally, that the
user would not have approved of had he/she known about it.)

A trojan horse is a program which is concealed inside another, for the
purpose of executing inside another user's protection boundary (on his
PC, or in a job he runs on a system, or in his virtual machine in VM).

( The term also applies to programs which masquerade as others, as
might a password-stealing program which emulates a legitimate system,
and thereby fools a user into entering a password, which the TH then
"steals".  A compiler which, when executed, copies an unrelated file
to the compilerdiskette would be an example, too. )  Is this strictly
true?  I thought a Trojan Horse actually did something also.


WORM

A worm is a program which replicates itself through a network,
generally with the goal of consuming more system resources than would
be otherwise available to it.


VIRUS

A virus is, to quote Fred Cohen, "a program that can 'infect' other
programs by modifying them to include a possibly evolved copy of
itself".

A virus is a program which attaches itself to other programs (or
possibly to a disk, although that is a minor distinction in my view;
it is then attaching itself to the boot record, which is a program)
and when it gets control, attaches itself to more programs.  It may
also take some action, possibly at random or timed, in addition to the
replication.

Well that's it, who's Fred Cohen?

Thanks in advance ( we should abbreviate that, in the time honoured
tradition, like the best things are in computing to "T.I.A."  what do
you think?)

                                        Steve.

------------------------------

Date:         Mon, 27 Feb 89 08:34:42 MST
From:         Jim Howard <[e-mail]>
Subject:      Lab Procedures

We have a number of IBM-PC networks with read only file servers. We
have never had a virus problem there in their 5 years of existance. We
can boot from the network due to boot proms on our network interface
cards.  Our Appletalk/Mac labs are another story. We have to go thru
the disk washing procedure like many others here have described. We
would like to have a network interface card with a boot prom on our
Mac's also.  We would need a faster interface such as ethernet, but
the extra speed would benefit the customers as well as give everyone
some security from infection. We have been showing every Apple person
we get on campus how well our IBM labs work and saying we need the
ability to boot from Mac networks. Most Mac II ethernet cards have an
empty PROM socket and there is a mention of optional Prom functions in
the Apple adapters documentation. A scheme (or modification to MAC OS)
would have to be developed to allow people to customize their own
screens, desktops, etc.  as they are accustomed to. Of course the very
nature of the Mac OS and its modification of files (resources, etc) is
tailr made for the infection process of viruses.  Regardless the
ability to be able to boot from a network file server is very high on
our wish list from Apple. It would be well worth the additional cost
of an ethernet card for every Mac.

------------------------------

Date: Tue, 28 Feb 89 14:37:50 CST
From: Kenneth W. Loafman <convex![e-mail]>
Subject: Re: Closed virus list proposal

I am against the formation of the list for a list of reasons:

1) I have yet to see a 'live' virus of any description and I have
downloaded and run probably 30Mb or more of PC software in the last
year.  How do I know that this list will not be the basis for the
creation of the first virus I will see?  How can I trust you any more
than you can trust me?

2) The information on how to 'protect' from viruses, if it is not to
be commercial, will tell how to build the very viruses that they
protect against.  How do I accept someone's word that the virus
protection program someone is hawking for $100 is useful much less
whether it is a valid program unless I know how it works?  If I know
how it works, what's the advantage of the list?

3) I do know how to build viruses.  What I'm looking for in this list
is further information on what else can be done to protect against
them.  I cannot get that information without being able to write them
as well.  Item 1 above led me to the construction of a couple of test
cases so I could check out a hardware solution to the problem using a
hardware debugger.  >From the descriptions of the viruses on the PC so
far, this solution should be complete, i.e. a software virus should
not be able to get past hardware protection methods.  I'm still
looking for a 'live' virus to try it out on.

4) I _refuse_ to purchase commercial software for virus protection and
may need all the informational help I can get.  Crime should not pay
for anyone and we all need to band together to keep the virus scare
from producing yet another market segment.  The formation of a private
list fosters that market segment by keeping information secret.

Now before anyone accuses me of heresy, let me add another comment.
If the list is formed, I need to be on it.  I do a great deal of
collection and review of PC software for the North Texas PC Users
Group and have valid need for the information that might be withheld
if this list is formed without me.  A single virus that slips past the
reviewers could fan out to several hundred people in a very short
time.  That would be very bad news!

- -----
Kenneth W. Loafman @ CONVEX Computer Corp, Dallas, Texas
email:  {allegra,uiucdcs,ctvax}!convex!loafman
phone:  [phone]

------------------------------

Date:         Mon, 6 Feb 89 16:31:25 EST
Sender:       SECURITY Digest <[e-mail]>
From:         FLORY <[e-mail]>
Subject:      Virus psychology information

In response to "Commander Spock"'s question about sources of
information on why people write virus's, I suggest he look at a few
recent magazine articles (I really doubt any books have been on the
topic as of yet)

In the Summer issue of 2600 magazine there is an article by "The
Plague" called "How to Write a Virus: The Dark Side of Viruses".  He
claims to have written a viruse called CyberAIDS which attacks the
Apple II series, but besides his "qualifications" you can get a pretty
good idea of the twisted kind of mind who enjoy this kind of thing
(Mr. "Plague" claims to have no moral objections to trashing people's
hard work) The article goes into the theory of virus writing (not
system specific) A careful reading between the lines can provide a
psycological outline of one kind of virus writer.

you can get a back issue of 2600 by writing to 2600 Magazine, PO Box
752, Middle Island, NY 11953-0752.

You also may want to look up the Winter 1988 issue of "High Frontiers
Reality Hackers" for an article called "Cyber Terrorists / Viral
Hitman" Reading it between the lines also reveals a lot about the type
of person who would voluntarily release a virus.

David James Flory

PS I don't support, condone, or agree with any of these authors, I am
just bringing them up for a view of why people would write these
things.

------------------------------

Date:    Thu,  2 Mar 89 13:47 CET
From:    "Jelle Uenk" <[e-mail]>
Subject: Flushot+ 1.51 question (PC)

I've used FluShot+ 1.51 now for two weeks, and I'm quite satisfied
with it. I've noticed some strange behaviour when using PC-Tools (I
believe its version 4.5 (?)). Even with FSP installed I'm able to
rename, delete etc. the system files command.com, ibmbio.com and
ibmdos.com. When I try to do the same with any other utility (and
DEL/REN on the commandline too) FluShot behaves as expected: It warns
about the action.  I'm wondering what I'm doing wrong with my setup of
FSP+.  Or is PC-Tools using some very special method of writing to the
harddisk? (It uses neither INT13 nor INT26 for the DEL/Rename, because
if I EDIT (with PCTOOLS) COMMAND.COM FluShot gets triggerd).

Can anyone give me some more information?

Jelle Uenk
Student Assistent
Leiden University - The Netherlands

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest              Monday, 6 Mar 1989          Volume 2 : Issue 58

Today's Topics:
Why write viruses
bouncing ball virus (PC)
special list, just say no.

---------------------------------------------------------------------------

Date:     Thu, 2 Mar 89 15:27 EST
From:     <[e-mail]>
Subject:  Why write viruses

In VIRUS-L V2no57 "Michael J. Steiner  " <[e-mail]> writes:
>The people who write viruses are usually (if not always) people who
>are very knowledgeable about computers. Being very knowledgeable about
>computers, these people might look down upon novices, and might write
>a virus, which would mostly affect novices (who sometimes barely even
>know that viruses exist) while not affecting other experts (who are
>aware of viruses and know the necessary precautions to avoid
>infection). Thus, a virus-writer can get pleasure out of
>confusing/disrupting the novices' efforts at learning about computers.
>(I hope I explained this clearly enough.)

Hmmm....interesting, but a little too broad in my opinion Mike.  A
little less generalization would probably make this a lot more
plausible. Okay, yes, occasionally wizards/gurus do like to put one
over on the less experienced, because the naive user has been and
probably always will be a subject of amusement to cognescenti in a
limited sense.  But by the time they know enough to wear the label, I
think they are also mature enough to know that: A. Viruses are just
NOT done to begin with.  B. Directed, intentional maliciousness
against the unknowing is not done either and is usually considered not
terribly mature/kind.

The true hacker has both the knowledge of the system as well as the
knowledge of how to use that knowledge.  (You could argue the case of
RTM as someone who went against this, but his original intentions were
to supposedly wake us up to the lax security on the net and not to
just go out and infect machines so he could laugh at all the people
whose machines were going down.)  [This is is no way a defense of what
he did, or an attempt to start up the "Light Side/Dark Side Hacker"
issue again.]

I would say that the majority of viruses are written for one of the
following reasons:
1. Immature people who do it just to say they did it, or because they
   thought it was "cool" or "in"
2. Disgruntled/Vengeful ex-users/ex-employees out for revenge.
3. An attempt to dispense the virus-writers own brand of "justice" by
   punishing certain users. (ala the supposed motive behind the
   creation of (c)BRAIN)
4. An attempt to scare up business for anti-virals.
5. Espionage (haven't seen this one yet, Thank God!)

Steve
- -------------------
Steve Okay [e-mail]/[e-mail]/CSR032 on The Source

                        "Join today!!, free introductory offer to new
                        members! Its the `Beam Weseley Crusher into a
                        Bulkhead Society' "

------------------------------

Date:     Fri,  3 Mar 89 16:08 N
From:     ROB_NAUTA <[e-mail]>
Subject:  bouncing ball virus (PC)

Hello.

A few months back our university was hit by a virus which spread
itself by modifying the bootsector and storing itself and a copy of
the original bootsector in a bad cluster. This may be an old one to
you, but here it was discovered recently. It can be stopped easely by
restoring the bootsector or by using protection like FluShot+. I am
disassembling the code, but I got a few questions:
- - Is this virus known ?
- - how does it work exactly ?
- - what are its actions ?
- - It spreads through bootsectors on bootable disks, but is there a 'seeder'
  program, a COM or EXE file that releases the infection when run ?
- - If such a program exists, what is it called and has it been spotted
  recently?

Any help would be appreciated
At the moment the only thing the virus does is show a bouncing ball
that bounces off text and the side of the screen and appears without a
reason or sometimes after heavy disk access. But I am afraid there is
a counter inside that makes it do worse things, like format disks.

Greetings

Rob J. Nauta
RCSTRN @ HEITUE51

------------------------------

Date: Fri, 3 Mar 89 11:19:47 CDT
From: Len Levine <[e-mail]>
Subject: special list, just say no.

I agree with Kenneth W. Loafman <convex![e-mail]> in his
statement that a closed virus list is a bad idea.

I have had about the same experiences as he has and would expect that
if such a list were formed, I would need to be on it too.  Who would
admit otherwise?

+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
| Leonard P. Levine               e-mail [e-mail] |
| Professor, Computer Science             Office [phone] |
| University of Wisconsin-Milwaukee       Home   [phone] |
| Milwaukee, WI 53201 U.S.A.              Modem  [phone] |
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest              Monday, 6 Mar 1989          Volume 2 : Issue 59

Today's Topics:
Macs with wills of their own...
Bouncing Ball (PC)
Why write viruses

---------------------------------------------------------------------------

Date:     Mon,  6 Mar 89 10:28 EST
From:     John McMahon - NASA GSFC ADFTO - 301-286-2045
          <[e-mail]>
Subject:  Macs with wills of their own...

$ Set Disclaimer=On

The following is intended as a query only.  I do not have enough facts
(in my opinion) to submit an "alert" message...

$ Set Disclaimer=Off

Recently, a friend at a nearby academic site told me about a problem
they were having with their networked Macs.  Users had reported that
the cursor/pointer on the Mac would pick up objects and drag them to
the trashcan without any action from the user.  I have heard of
teaching things to clean up after themselves, but this is a tad
ridiculous :-) They suspect some sort of a Virus, however nothing has
been confirmed.

Any ideas ?  Anyone seen this before ?

Thanks in advance,
+--------------------------------------------------------------------------+
|John McMahon                             "Invest heavily in SPAM futures" |
|Advanced Data Flow Technology Office                                      |
|Code 630.4                            Arpa: [e-mail] |
|NASA Goddard Space Flight Center    Bitnet: FASTEDDY@DFTBIT               |
|Greenbelt, Maryland 20771             Span: SDCDCL::FASTEDDY (Node 6.9)   |
+--------------------------------------------------------------------------+

------------------------------

Date:  Mon, 6 Mar 89 12:17 EST
From:  "Joseph M. Beckman" <[e-mail]>
Subject:  Bouncing Ball (PC)

The "bouncing ball" virus sounds like a modification of the Pakistani
"Brain" virus.  Everything except for the bouncing ball, that is.  Is
there another program around that has done this ball trick?  That is,
has someone just spliced the Brain code with this ball code, or did
they actually do a little more coding of their own?

Joseph

------------------------------

Date: Mon, 6 Mar 89 14:17:56 EST
From: [e-mail] (Joe Sieczkowski)
Subject: Why write viruses

>5. Espionage (haven't seen this one yet, Thank God!)

That's what makes it scary!

Joe

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest             Wednesday, 8 Mar 1989        Volume 2 : Issue 60

Today's Topics:
Bouncing Ball (PC)
Bouncing balls, Falling letters, et cetra...
notorizing
re: Macs with wills of their own...
Re: Macs with wills of their own
PC Bouncing Ball virus (or is it?!)


[Ed. There's been quite a rash of messages sent to the list lately
that were intended for the LISTSERV (e.g., INDEX, LIST VIRUS-L, GET
VIRUS-L LOG8811A).  This is a reminder to everyone that LISTSERV
commands have to be sent to the LISTSERV, not to the list itself.  The
address of the LISTSERV is [e-mail] or
[e-mail] (either will work).]


---------------------------------------------------------------------------

Date: 6 March 1989, 16:48:47 EST
From: David M. Chess    <[e-mail]>
Subject: Bouncing Ball (PC)

Well, I've seen a boot-sector virus that did that.  It didn't seem to
be related to any other virus I've seen (code very different from the
Brain and so on).  It would infect both hard and floppy disks, and the
only obvious effect was the little bouncing face.  No EXE or COM file
involvement found or suspected.  Of course, what you have may be an
entirely different virus, with the same screen effect!
                                                  DC

------------------------------

Date:     Mon, 6 Mar 89 17:04 EDT
From:     <[e-mail]>
Subject:  Bouncing balls, Falling letters, et cetra...

        Joseph asked if the author of the Bouncing Ball virus wrote
any new code, or just simply spliced a previously written routine to
the (c)Brain virus.  Well the bouncing ball routine has been floating
around in Public Domain for awhile, and other routines used in viri
tend to be culled from similar sources.  The falling letter routine,
which is also available in the public domain, is another example of
public domain code that has been added to viri.  The authors of these
viri do not even posses the creativity to code their own "joke"
routines.  A collection of such routines is available on a disk called
"Jokes" from Public Brand Software.  I am in no way affiliated with
PBS, and I am certain many other public domain clearing houses have
such a disk, I am just more familiar with PBS's catalogue.

Rushdie lives and is hiding in the              Mark James Burge
Chi Phi Fraternity@OWU                          [e-mail]

------------------------------

Date:  Mon, 6 Mar 89 17:55 EST
From:  [e-mail]
Subject:  notorizing

    Cryptography can provide very strong tools for protecting computer
systems from virus attacks.  One particularly useful cryptographic
tool for eliminating viruses would be "cryptographic notarization".
The notorization would provide a strong sealing of the integrity of a
file or disk.  Software could be notarized by "certification
authorities".  The certification authorities would be distributed and
hierarchical.  This would allow every commercial software house to be
its own notorizing authority.
    The notorization would not prevent the distribution of malicious
code, but would provide strong integrity and traceability of the code.
For example, the integrity of a copy of LETUS-123 could be verified by
any user with this scheme.  This would provide strong proof of the
softwares origin and that it had not been modified.  If the LETUS-123
had any flaws or virus within it, it would be traceable to the
originating software house.
    In the ongoing discussion in this forum I have noticed several
misconceptions about cryptography.

>.................... a simple virus like Brain will spread regard-
>less of program encryption, because it attaches to code that could be
>stored encrypted.

    First cryptography is not just encryption.  Cryptography is
mechanism to provide many "security services" that include -
confidentiality, integrity, peer entity authentication, and data
origin authentication (see ISO 7498-2).  Contrary to the following
comment, any mechanism for a cryptographic protection mechanism must
be based on standards.

>Such an encryption system would only be useful if it were not
>standard.  If it became standard, or at least widely distributed,
>viruses would work their way around it .....

    To support the development of real cryptographic devices,
standards must be available to ensure interoperability.  The issues of
a virus working their way around an implementation are not relevant to
the development of the standards.  Only the local implementation of a
verification mechanism must be conserned with these issues.

    Standards already exist that could be used for these mechanisms.
Considerable work is available as a foundation from ISO (DIS 9594-8),
ECMA (TR/46), FIPS, ANSI, CCITT, and IEEE (802.10).  The challenge at
hand is then to integrate these existing mechanisms into a complete
system solution.  I would strongly recommend as a start for the
notorization system the ISO DIS 9594-8 specification, in combination
with RSA, and a DES MAC.

Paul A. Lambert    | Motorola GEG           | Secure Network Section |
                   | 8201 E. McDowell       | Scottsdale, Az. 85252  |
docmaster.arpa | [phone]         |

------------------------------

Date:     Tue,  7 Mar 89 00:03 EST
From:     <[e-mail]>
Subject:  re: Macs with wills of their own...

John,

You recently asked in the Virus mailing list about Macs throwing
things in the trashcan on their own.

Farralon Computing (sp?) now has available a product called "Timbuktu"
for networked Macs. This lets a user on one Mac watch and/or
manipulate any other Mac on the network that is also running Timbuktu.
It is a godsend for Mac network managers who have to clean up after
people who leave things in disarray, particularly when the Macs are in
several buildings.  It is a disaster when the users start using it on
their own.  Passwords are optional.

Your reporter may have seen this in use without being aware of it.

Selden E. Ball, Jr.
(Wilson Lab's network and system manager)

Cornell University                 Voice: [phone]
Laboratory of Nuclear Studies        FAX: [phone]
Wilson Synchrotron Lab            BITNET: SYSTEM@CRNLNS
Judd Falls & Dryden Road        Internet: [e-mail]
Ithaca, NY, USA  14853       HEPnet/SPAN: LNS61::SYSTEM = 44283::SYSTEM

------------------------------

Date: Tue, 7 Mar 89 01:42 EST
From: "Mark H. Anbinder" <[e-mail]>
Subject: Re: Macs with wills of their own

Your description of the Macintosh cursor picking up files and dragging
them to the trash with no user action sounds like Timbuktu may be
involved.  Timbuktu is a program that allows a user on one Macintosh
to control ANOTHER Macintosh across a network.

If, when this is happening, there is a small "hand" icon in the upper
right hand corner of the screen (in the menu bar) then it IS Timbuktu,
and someone else on the network is playing a stupid joke.  If not, you
may have stumbled across an interesting problem.

Any chance someone set up a macro that the users are playing back
without realizing they're doing it?

Mark H. Anbinder
Department of Media Services
Cornell University

------------------------------

Date:     7-MAR-1989 15:43:42 GMT
From:     Jason Brown <[e-mail]>
Subject:  PC Bouncing Ball virus (or is it?!)

I remember a program like this, only it wasn't a virus. (Note that I'm
not saying that *this* one isn't a virus!).

When the program was run, a smiley face would start bouncing around
the screen, rebounding off any text that was displayed. When the
screen scrolled, sometimes the face would get stuck between a bunch of
letters.

By pressing various combinations of keys you could increase or
decrease the number of faces. If you got rid of all of the faces, they
would come back after a period of activity (about half an hour, I
think). I seem to remember that it was supposed to survive a warm
reboot, but I can't be certain.

This was all a fair while ago. I think the program was called
FACE.COM, or something similar. It either came with a small document
file describing the various keys used, or it printed them up when the
program was run.

Sorry I can't be more precise. I still have a copy of the program, but
it is at home. If you are still interested, I can check up when I go
back in a couple of weeks for Easter. If this is the program you are
experiencing, then there is no need to worry - it is not a virus.
Turning the machine off will get rid of it. (Check the AUTOEXEC.BAT
file to check that it is not loaded when the machine is booted).

- -NOTE- The program described in this message may not be the one you are
       experiencing. Do not relax your security measures.

- -- Jason --

+------------------------------------------------------------------------+
|Jason Brown                                                             |
|    JANET           : [e-mail]                          |
|    BITNET/EARN     : [e-mail]                          |
|    Internet/ARPAnet: [e-mail]          |
|    EAN/X400        : [e-mail]                          |
|    uucp            : ...psuvax1!cunyvm.bitnet!vaxb.aston.ac.uk!BrownJS |
+------------------------------------------------------------------------+

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest             Thursday, 9 Mar 1989         Volume 2 : Issue 61

Today's Topics:
Cartoons and wily hackers
Re: Bouncing ball virus (PC)
Warning: Urgent: A CHRISTMAS EXEC is around (IBM REXX)
BUL EXEC - second issue (IBM REXX)
Notarization
re: notorizing

[Ed. Please be advised that April 1 (fool's day) is rapidly
approaching; it is not uncommon on the networks to find fake e-mail
every year around this time.  I will do my best to keep such mail from
making it into a digest...]

---------------------------------------------------------------------------

Date: Wed, 8 Mar 89 09:52:59 est
From: ubu![e-mail]
Subject: Cartoons and wily hackers

A couple of topics that have gotten a lot of attention recently on
RISKS, among other places, are the use of cartoons to talk about
viruses and the arrest of three West German "computer spies" (for lack
of a better name).  I thought I'd mention this here to find out what
peoples' thoughts are on the subjects.

Recent Dick Tracy (and reportedly other) comic strips have portrayed
viruses and virus authors (the Dick Tracy strip apparently has a
character who is using a virus for extortion).  RISKS readers seem to
think (by and large) that comic strips aren't too bad for talking
about these things *if* they are portrayed accurately.  Any thoughts?

Also, those of us who've read Cliff Stoll's "Stalking the Wily
Hacker" will be interested to hear that three people have now been
arrested in West Germany in regards to the case described by Dr.
Stoll.  While this isn't directly virus related, it is interesting to
note that the suspects used various computers and networks for
espionage purposes.  It will also be interesting to see the outcome of
the case in the courts.

Ken

------------------------------

Date:        Tue,  07 Mar 89 16:31:28 +0200
From:        Y. Radai <[e-mail]>
Subject:     Re: Bouncing ball virus (PC)

  In #58 Rob Nauta asked about the bouncing ball virus.  This was
described in #18 (18 Jan), where I referred to it as the Ping-Pong
virus.  As I described it then,

>                                                   It is a virus
>which first appeared in Israel [in October 1988], and which got
>its name because of a bouncing point which appears on the screen.
>Like the Brain virus, it resides in the boot sector of disks, in bad
>sectors, and in high RAM.  ....
>  Among the points in which it differs from the Brain virus: (1) It
>infects hard disks, not only 5 1/4-inch floppies.  (2) It marks only
>one cluster as bad.  (3) It grabs only 2K of high RAM.  (4) To the
>best of my knowledge, it does not cause any damage to files or to the
>FAT.  In particular, the bad sectors seem to always be chosen from
>unused clusters.

  The bouncing dot appears only under very special conditions: when
(1) the system clock shows a multiple of 30 minutes and (2) the disk
is being accessed.  The simplest way to force the dot to appear (if
RAM is infected) is to enter TIME 0 and then immediately type a cha-
racter and press Enter.  (Even after the dot appears, you can continue
working.  The dot will disappear only when you reboot or turn off the
computer.)
  Other symptoms: 2K missing from RAM (or a multiple of 2K if infec-
tion has taken place more than once); one bad cluster on disks.  Both
of these can be checked by performing CHKDSK, of course.  If you see
1K in bad sectors on a diskette, that's a pretty sure sign of this
virus since FORMAT marks bad sectors in blocks of 5K.  (Anyone know
why?)  Note that when the virus marks the bad cluster, it does so on
only one copy of the FAT.
  Finally, the virus causes access to diskettes to be slower because
of the attempts to infect them.
  It seems to be more contagious than the Brain virus; presumably the
main reason is its infection of hard disks also.
  In response to Rob's other questions, I'm fairly sure that there's
no counter which will trigger further damage when it reaches some
specified value, and that there's no specific "seeder" program.
However, when Rob said that it spreads on bootable disks, he
presumably meant *only* bootable disks, which is incorrect: like
Brain, it also spreads on non-system diskettes.  (They too have boot
sectors.)
  At the time I posted my earlier article, I had not heard of this
virus outside of Israel, so I assumed that it was a local product.
Since then I've heard of it (or something very similar to it) in the
UK (in May 88) and in Italy (and now in the Netherlands).  In the UK
it is referred to as the Italian virus since it was traced (by Dr.
Alan Solomon) to Torino, Italy.  (Some of the information given above
was supplied by him.)
  In answer to Joseph Beckman's question, this virus is not just a
splice of the Brain virus with ball code.  On the one hand, it infects
hard disks too; on the other hand it's considerably smaller than Brain
and lacks some of Brain's features, such as feeding you the contents
of the original boot sector when you try to look at the infected boot
sector.

                                           Y. Radai
                                           Hebrew Univ. of Jerusalem

------------------------------

Date:         Wed, 8 Mar 89 16:19:26 GMT
From:         nad Turgut Kalfaoglu <[e-mail]>
Subject:      Warning: Urgent: A CHRISTMAS EXEC is around (IBM REXX)

From Linkfail list:

A user here wrote a file called BUL EXEC which can distribute itself
by using userid() NAMES.. it is almost identical to CHRISTMAS EXEC,
but different picture.. Checks :node tag as well, and can jump from
node to node..  The link will be down until we clean the problems
here. -turgut

------------------------------

Date:         Wed, 8 Mar 89 20:40:46 GMT
From:         Turgut Kalfaoglu <[e-mail]>
Subject:      BUL EXEC - second issue (IBM REXX)

A follow up on BUL EXEC.........

- ----------------------------Original message----------------------------

After several hours of automatic reader scanning, there are no more
copies of BUL EXEC on spool areas on TREARN. There are some that are
RECEIVED to disks, but I have sent several warnings, and will be
notifying everyone on this. I have a disconnected-running program to
scan the RSCS queue repeatedly, and will be purging them if it comes
accross a copy.  Fortunately, we discovered the program, 10 minutes
after it was released, by its author who warned us.

I hope, and don't think that the file has jumped to the FRMOP22 line,
but it may have jumped to the other Turkish nodes. (I have closed the
FRMOP line for several hours due to this).  Again, the filename is BUL
EXEC, and it is a christmas exec (it sends itself to everyone on NAMES
file) Regards, -turgut

------------------------------

Date:     Wed, 8 Mar 89 16:13:47 EST
From:     Jefferson Ogata (me!) <[e-mail]>
Subject:  Notarization

>>.................... a simple virus like Brain will spread regard-
>>less of program encryption, because it attaches to code that could be
>>stored encrypted.

I think this is a misquote.  The original message said Brain will
spread because it attaches to code that canNOT be stored encrypted.
This was in reference to yet another suggestion that encryption (not
cryptography in general) be used to keep executable files in a
protected state, only to be unencrypted before execution.  I'd like
to remind readers that this scheme has important flaws: namely, the
encryption program itself can be attacked; and the operating system
can be attacked (by such as Brain).

Regarding the idea of notarization of programs, I must assume you
are referring to some method of distributing signatures of some
kind, to be compared with signatures computed by the user who wants
to know if a program is secure.  It has been pointed out several
times that if some channel exists whereby these signatures can be
distributed without corruption, there is no reason why the programs
themselves could not be distributed by the same channels.  One must
consider where the user needing authentication is going to acquire
signatures: probably the same place he got the program -- a bulletin
board.  Such signatures would be just as easily corrupted as the
programs in question.

In order for a signature verification method to be viable, someone
must come up with a method for verifying the signatures.  Perhaps
when this has been accomplished, we might discuss standards for
signature generation.  The operating system and signature-computing
program are still healthy targets for attack.

If you have some way of verifying signatures, or if you are talking
about an entirely different mode of protection, I'd be very inter-
ested to hear about it.

- - Jeff Ogata

------------------------------

Date: Thu, 9 Mar 89 00:36:53 EST
From: Don Alvarez <[e-mail]>
Subject: re: notorizing

Paul Lambert suggests that cryptographic notorizing is the solution to
viruses, and then goes on to state:

" To support the development of real cryptographic devices, standards
must be available to ensure interoperability.  The issues of a virus
working their way around an implementation are not relevant to the
development of the standards.  Only the local implementation of a
verification mechanism must be conserned with these issues."

NOT TRUE!!!
A standard is ONLY of value if you can PROVE that it can be
implemented without theoretical weaknesses.  Any cryptographic
solution includes some black-box which does the magic to check the
notorizing value, encrypt the password, or whatever.

Unless that black-box is designed into the physical architecture of
the computer you get NO PROTECTION from it.  Why? because you can't
trust the black-box.  There is and will continue to be an enormous
installed base of PC's, Vaxen, Suns, etc.  These existing machines do
not have any special notorizing hardware attached.  That means either
you force every IBM-PC user to install some $500 board in his machine
that probably won't be compatible with his existing software, OR you
modify his MS-DOS do to the cryptographic checks in software.  The
hardware solution is prohibitively expensive, and the software
solution is worthless.  The software solution is PARTICULARLY
worthless if it's standardized (as many others have pointed out)
because if it's standardized, then somebody has a standard they can
set their virus to attack.  DOS on your hard disk is just like any
other file.  It can be attacked and altered by viruses.  It is true
that there are excellent secure communication models for sharing data
over an untrusted medium between mutually untrusting hosts (see
Needham and Schroeder, for example, or any of the alphanumeric strings
that Mr. Lambert quotes to prove this is all a solved problem) but all
such models assume that the local magic box can be trusted.  As long
as the magic box is reprogrammable it is fundamentally untrustworthy.

You can't use software to protect yourself against viruses, because
software can be reprogrammed by the very computer you are trying to
protect.  You can't use hardware to protect existing computers against
viruses, because it's not economically feasible.  The only machines
you can have any hope of absolutely protecting against viruses are
next-generation machines which have watch-dog hardware built in (and
I'm not even convinced that's possible).

Standards are all well and good, but you HAVE to think about how they
are going to be implemented, because if it can't be implemented
securely, your standard isn't any good.

I will be accused of being negative and pessimistic.  That is true.
If you are designing a security system you HAVE to assume the worst
case, and the worst case in this case is that somebody writes a virus
to attack the cryptographic software which your machine depends on.

                        - Don

     + ----------------------------------------------------------- +
     |   Don Alvarez               MIT Center For Space Research   |
     |   [e-mail]      77 Massachusetts Ave   37-618   |
     |   [phone]            Cambridge, MA 02139             |
     + ----------------------------------------------------------- +

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest              Friday, 10 Mar 1989         Volume 2 : Issue 62

Today's Topics:
Bouncing ball (PC)
Alameda virus? (PC)
Possible Virus protection
Flu_Shot+ queries answered (PC)
Brain virus infection (PC)
bouncing ball virus (PC)

---------------------------------------------------------------------------

Date: 9 March 89, 13:12:01 MEX
From: Mario Camou Riveroll <[e-mail]>
Subject: Bouncing ball (PC)

Here at the Monterrey Tech (Mexico City campus) we had an epidemic of
the bouncing ball virus. This strain lodged itself in a couple of
"bad" sectors (it marked them as bad in the FAT). There seem to be at
least 2 strains, one that doesn't seem to have any adverse effects and
another one that scrambles up the FAT and root directory. That's as
much as I know about it. We call it the Italian Virus (don't know if
this helps).

Mario Camou
EM302723@VMTECMEX
"Those who can, do.
Those who can't, teach.
Those who can't teach, manage."

------------------------------

Date: 9 March 1989, 16:01:10 EST
From: David M. Chess <[e-mail]>
Subject: Alameda virus? (PC)

John McAfee's article in the Feb 15 issue of Datamation, "The Virus
Cure" (good article, poor title) lists a boot-sector virus that he
calls the "Alameda Virus".  I've never heard that name before, and it
isn't on Dave Ferbrache's February list.  It does sound sort of like
the "Yale" boot virus (which McAfee doesn't list under that name);
does anyone know if the two are in fact the same?  If not, does anyone
know any more about the "Alameda"?

DC
Watson Research

------------------------------

Date:     Thu, 09 Mar 89 22:18:14 -0900
From:     Reed Rector <[e-mail]>
Subject:  Possible Virus protection

     It seems to me that global methods of virus checking are limited
by their scope. If there is an accepted way for the system to check
for viruses, then people WILL find ways to get around it. On the other
hand, if all programmers are encouraged to include routines that look
for infection in every program they write, then the spread of viruses
can be greatly slowed.
     If each program were to keep itself free of infection though
methods developed seperatly by each programmer, then there would be no
"standard" way for viruses to invade the software. These checks could
be relativly simple checksum methods, but if each program has
different code (even if they do the same basic thing) to do these
checksums, then viruses could only carry patches for a few products.
This method of individual program protection could be forced on the
whole industry by only a few programmers. Once programs become
available that have a "virus resistant" seal of approvial, they have a
great advantage over competing products that don't. I'd be willing to
bet that the cost of these routines would more than pay for
themselves, while making the virus illiterate public safer.

        Thanks for your time,
                Reed Rector - Systems Programming, Univ of Alaska

                SXWRR@ALASKA (BITNET)
                [e-mail]      (Internet)

* Disclaimer: All of the above views are mine (assuming you believe in
free will), and in no way reflect the views of anyone else.

------------------------------

Date: Thu Mar  9 13:30:39 1989
From: utoday![e-mail]
Subject: Flu_Shot+ queries answered (PC)

(Sorry for the delay in responding...some hardware problems kept me
offline for close to three weeks!)

Paul: The checksum values shipped with the distribution copy of
FLU_SHOT+ are dummy values.  Although the next release will have an
easier installation package, you simply must run the code, copy down
the expected checksums, then edit them into the FLU_SHOT.DAT file.  I
didn't want to have the checksum routines in two places initially as
an additional security precaution.

Jelle: I'm in the process of invetigating what PCTools does which
permits it to get around FSP1.51 - stay tuned for the next release,
which will [hopefully] solve the problem.

Ross
Ross M. Greenberg
UNIX TODAY!             594 Third Avenue   New York   New York  10016
Review Editor           Voice:(212)-889-6431  BBS:(212)-889-6438
uunet!utoday!greenber   BIX: greenber  MCI: greenber   PCMagNet: 72241,36

------------------------------

Date: Thu Mar  9 13:41:19 1989
From: utoday![e-mail]
Subject: Brain virus infection (PC)

Rob: you were hit with what seems to be the so-called "Brain" Virus.

There does not appear to be a seeder program of any sort.  In general,
this virus takes over the BIOS interrupt for INT13, and takes a look
at the boot track on any disk it will [maybe] infect.  If it finds the
key of 1234 (as a number) stored starting at offset location 4 in the
boot track, it assumes that the disk is already infected and leaves it
alone.

Ross M. Greenberg
UNIX TODAY!             594 Third Avenue   New York   New York  10016
Review Editor           Voice:(212)-889-6431  BBS:(212)-889-6438
uunet!utoday!greenber   BIX: greenber  MCI: greenber   PCMagNet: 72241,36

------------------------------

Date:     Fri, 10 Mar 89 14:03 N
From:     ROB_NAUTA <[e-mail]>
Subject:  bouncing ball virus (PC)

Thanks everybody for the replies. I can answer some questions. First
of all it's not the face.com joke program, it's a real bootsector
virus. It is indeed like someone described a virus that marks one
sector bad, not three like the brain virus i read about in the
magazine Computers & Security. Defeating it is easy but I'm glad there
is no additional counter or timer. I found the following in the code
of the bootsector..

XOR     AH,AH
INT     1A
TEST    DH,7F
JNZ     0203
TEST    DL,F0
JNZ     0203
PUSH DX
CALL    03B3

INT 1A with AH=00 gets the time of day. This explains the assumed
irrational behaviour: the virus appeared on IBM PC's but not on some
others (i mean the ball part). I could never get it to bounce at home,
probably because of the differences in cold boot time (the ibm takes
forever)... and why it would appear after a cold boot but not after
some warm boots..

Rob J. Nauta

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest              Monday, 13 Mar 1989         Volume 2 : Issue 63

Today's Topics:
Computer Security Conference in NJ
Espionage
Notarization
Use of Digital Signatures
Use of Digital Signatures
Re: Macs with wills of their own
Merry Christmas... I think :-(

---------------------------------------------------------------------------

Date: Fri, 10 Mar 89 09:10:26 EST
From: [e-mail] (Joe Sieczkowski)
Subject: Computer Security Conference in NJ

Apparently someone's holding a computer security conference soon.

[Taken from IEEE Newsletter, March 1989, Vol. 35, Number 9]
[Reprinted without Permission]

   On March 23, 1989 the North Jersey Joint Computers and
Communications Society will meet to hear a talk on "Computer
Security." The speaker will be Dr. Roy S. Freedman of the Polytechnic
University.  This meeting replaces the one planned on March 22nd
entitled "Cryptography" and will broaden the subject to include the
whole field of computer security.
                         ...[Cut Paragraph]...
   ...He [Dr. Freedman] will also discuss how some recent work in
cryptographis systems may thwart computer virus attacks, and how
computer surveillance should be used to assess the "health" of an
installation.
                         ...[Cut Paragraph]...
Time: 8:00 PM, Thursday, March 23, 1989.
Place: ITT Club House, 417 River Road, Nutley, NJ
Further Info: Elliot L. Gruenberg [phone]

[End of article]

Has anyone heard anything about this conference?
Perhaps its worth attending...

Joe

------------------------------

Date: Fri, 10 Mar 89 12:49:01 EST
From: [e-mail] (Joe Sieczkowski)
Subject: Espionage

All (or almost all) of the viruses/worms/trojans we have seen on the
list have been found because of one of the following:
  (1) An error [Lehigh virus, Internet worm]
  (2) It advertised itself [ping-pong, scores]
  (3) It blatently destroyed something [...(I'm sure you can think of some)..]
Most of which were propably developed and released immediately; ie V1.0
(I guess most of you had experience with V1.0 software packages :-)

Picture a group of programmers from firm "A" who wish to see their
competetor's (firm "B") data.  Firm A designs a virus that will place
a very special back-door in a computer system.  After the virus
successfully installs the back-door, it removes itself from the system
leaving no trace.  However, Firm A doesn't release it right away.
They put this very "controlled" virus on their own computer system for
testing.  They watch for symptoms, accumulate statistics, and wait for
their users to have trouble with normal operations.  After six months
or so, when the have all the bugs worked out Firm A manages to have
Firm B's computer infected.  In a certain amount of time (whatever
Firm A's statistics say), Firm A is pretty sure Firm B's computer
has the back door installed.  Firm A then proceeds to steal Firm B's
data through the back-door.

You have to start to wonder, if a single person can quickly hack out a
decent virus, what can a company do if they dedicate a team of system
programers to the project.

Joe

------------------------------

Date:  Fri, 10 Mar 89 21:38 EST
From:  [e-mail]
Subject:  Notarization

I would like to reiterate that - cryptographic notarization can be a
strong tool for protecting computer systems from virus attacks.  It is
not the only mechanism required for complete protection.  Other
components of a complete system might include strong memory
management, a "trusted" software base, and security policies and
procedures.  The policies and procedures are actually the most
important in that they are what most of us now rely on.

Since the only feedback on my proposal so far has been negative, I
would like to respond to Jeff Ogata's criticism:

>....  I'd like
>to remind readers that this scheme has important flaws: namely, the
>encryption program itself can be attacked; and the operating system
>can be attacked (by such as Brain).

Wrong.  Many mechanisms can be used to protect the software that might
check a "cryptographically sealed" program.  The simplest is to
restart a computer with the verification software on a disk with the
write protect tab set.  Other schemes are possible and are independent
of the cryptography and data formats.

>   ...   It has been pointed out several
>times that if some channel exists whereby these signatures can be
>distributed without corruption, there is no reason why the programs
>themselves could not be distributed by the same channels.

I am proposing a hierarchical notarization system.  Only one piece of
information and the verification software, or hardware, must be
delivered to all users.  All further notarization signatures are
delivered with the "sealed" information.  This means that "untrusted"
means can be used for the distribution of the software and the
softwares signature.  If you are interested please read ISO 9594-8
(aka CCITT X.509).

>   ...  Such signatures would be just as easily corrupted as the
>programs in question.

Wrong.  Read any recent article on public key cryptography.

In response to Don Alvarez's comments that:

>A standard is ONLY of value if you can PROVE that it can be
>implemented without theoretical weaknesses.  Any cryptographic
>solution includes some black-box which does the magic to check the
>notorizing value, encrypt the password, or whatever.

It is interesting to note that public key algorithms are based on
NP-complete algorithms (eg RSA).  In this branch of mathematics, know
as complexity theory, it possible to prove that the problem in the
class NP-complete, but not if a particular problem might be "solved".
In particular, the RSA scheme would be weakened if a major
breakthrough was made in the factoring of numbers.  This is very
unlikely, but not provable.  The RSA algorithm, even with this slight
uncertainty, is considered to be "good".  This is an interesting
topic, but I believe that Don was referring to issues relating to
proving implementations correct.  He is correct that this is desirable
for a specific implementation.  I still maintain that the development
of a software notarization standard is independent of these
considerations.

>Unless that black-box is designed into the physical architecture of
>the computer you get NO PROTECTION from it.

Yes, but the "black-box" could be software.  The minimum required of
the physical architecture is a reset switch and a disk write protect
mechanism.  I would propose that given a single "trusted" verification
program, a system could be "bootstrapped" so that all installed
software was verified.  It is possible that a "sealed" program might
contain a virus.  This virus would be detectable if it altered any
other "sealed" information.  The source of the virus would then be
directly traceable to the notarization authority, in this case the
issuing software house.

Once again, the software notarization does not solve all computer
security problems.  Policies and procedures are still required to
ensure the correct usage of this tool in existing systems.  Future
computing systems could provide more assurances and the verification
"black-box" in hardware.

Paul A. Lambert              Motorola GEG, Secure Network Section
Lambert -at docmaster.arpa   8201 E. McDowell
[phone]               Scottsdale, Az. 85252

------------------------------

Date:  Sat, 11 Mar 89 10:48 EST
From:  [e-mail]
Subject:  Use of Digital Signatures

Even in the face of digital signatures
>The operating system and signature-computing program are still
>healthy targets for attack.

True.  Digital signatures are not mechanisms for preventing attack.
Rather, they are mechanisms for preserving trust, fixing
accountability, and relieving the innocent.

If you corrupt my signature verification mechanism, I can no longer
rely upon it.  However, in the presence and use of such a mechanism, I
had to trust you before you could do that.  If I trust you, you can
always damage me, ONCE.  That does not diminish the value of knowing
that it is truly you (rather than someone pretending to be you) that I
can no longer trust.

William Hugh Murray, Fellow, Information System Security, Ernst & Whinney
2000 National City Center Cleveland, Ohio 44114
21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840

------------------------------

Date:  Sat, 11 Mar 89 10:32 EST
From:  [e-mail]
Subject:  Use of Digital Signatures

>It has been pointed out several times that if some channel exists
>whereby these signatures can be distributed without corruption,
>there is no reason why the programs themselves could not be
>distributed by the same channels.  One must consider where the
>user needing authentication is going to acquire signatures:
>probably the same place he got the program -- a bulletin board.
>Such signatures would be just as easily corrupted as the programs
>in question.

The signature can be distributed with the program.  If you verify it,
it will give you confidence that it has not been corrupted since being
signed.  If you trust the signer, you can trust the code.

Of course, you must have a trusted copy of the public key of the
signer.  You may get this from any trusted source (usually signed by
the private key of that source, whose public key you already have and
trust.)

You must also have a small trusted space in which to verify the
signature and store the keys.  This will usually be your PC and a
diskette for that purpose.  (We cannot trust the managers of shared
systems for this purpose.)

Note that this is not a mechanism for creating trust; it is only a
mechanism for maintaining and distributing trust which already
exists.

This does not require any invention or even implementation; an
implementation is already available and its use has been endorsed by
the Internet Activities Board.

William Hugh Murray, Fellow, Information System Security, Ernst & Whinney
2000 National City Center Cleveland, Ohio 44114
21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840

------------------------------

Date: 9  Mar 89  9:11 +0100
From: Danny Schwendener <[e-mail]>
Subject: Re: Macs with wills of their own

>If, when this is happening, there is a small "hand" icon in the upper
>right hand corner of the screen (in the menu bar) then it IS Timbuktu,

Note that there are other "foreign screen control" programs on the
marketplace.  One I'm particularly aware of is MoNet, by Juri Munkki
<[e-mail]> in Finland. His package does the same, but
does not display a warning on the foreign Mac, like Timbuktu does with
the "eye" or "hand" icons.

- -- Danny Schwendener
   ETH Macintosh Support

------------------------------

Date:         Sun, 12 Mar 1989 16:07 EST
From:         Grey Fox <[e-mail]>
Subject:      Merry Christmas... I think :-(

Oooh... Nasty christmas exec programs running around... It's an easy
concept to grasp once someone does it... But has anyone thought to
execute the original author of the damn thing? Oh well.. Anyway...

Anyone ever think that one reason hackers write viruses is to prove
that it can be done? I have a program that lowercases entire IBM VM
directories... Dangerous to run, but written to prove that it could
be done... And it could probably be hooked to a christmas exec spreader,
or some sort of virus thingy that would corrupt other Exec files in
a directory or a combination of the two... It has the potential to be
devastating. (Which is why I am not releasing it).
                        -Bruce Ide

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest             Tuesday, 14 Mar 1989         Volume 2 : Issue 64

Today's Topics:
Virus hysteria.
Re: PC Boot Sector Viruses
Reply on notarization
File lock protection?  (Mac)

---------------------------------------------------------------------------

Date:     Mon, 13 Mar 89 08:40 EST
From:     Cincinnati Bengals. <[e-mail]>
Subject:  Virus hysteria.

     I was wondering if anyone has comments on the way reports of
viruses seem to be given too much attention by the media.  As an
example, when our Mac's were hit by the nVIR virus, a local newspaper,
the Cincinnati Post, place a report of the virus on the front page.
The virus was a relatively minor occurance, start-ups were being
disabled, applications were being altered, but no loss of data.
Surely this is newsworthy, but front page?  This seems comparable to
placing reports on the front page every time the common cold breaks
out on campus.  Comments?

Tom Kummer

------------------------------

Date: 13 Mar 89 22:14 -0100
From: Jeff Raynor <[e-mail]>
Subject: Re: PC Boot Sector Viruses

      In issue #61, Y.  Radai discusses the "bouncing ball" virus and
 its spread outside of his area to other European countries.

      This made me think about the transmission method of these
beasts.  A straight-forward boot sector virus would only be spread by
the boot sector (physical media) and so wouldn't propogate across
serial lines ("electronic media": modems, BBS, "long distance"
networks) - but might on local nets.

      I would be interested to hear from those unfortunate to be
infected:

      Was the infection via an infected disk?
      Was the "culprit" disk identified?
      Was the disk created by a user?
      Was the disk formatted by a user?
      Was the disk from a software house?
      Was the disk received by post or by person?

      I realize that its naive to assume that you can only get
infected with .EXE viruses via a line or boot sectors with physical
media.  I would have thought that the disadvantage of propagation of
the boot sector types would have favoured the .EXE types.  However,
most of the PC viruses currently causing damage seem to be the boot
sector types.  Anyone in netland like to comment?

      Jeff Raynor
 EAN:  RAYNOR%RZSIN.SIN.CH
 Paul Scherrer Institut, Zurich, Switzerland.

------------------------------

Date:     Mon, 13 Mar 89 17:49:05 EST
From:     Jefferson Ogata (me!) <[e-mail]>
Subject:  Reply on notarization

>  ....  Many mechanisms can be used to protect the software that
> might check a "cryptographically sealed" program.  The simplest
> is to restart a computer with the verification software on a disk
> with the write protect tab set.  Other schemes are possible and
> are independent of the cryptography and data formats.

That's fine if you only want to check things once in a while; but what
are these other schemes?  And how do you protect your operating
system?  And you're ignoring the context of the remark: keeping
programs in an encrypted state until execution.  Surely you don't
propose to reboot the computer every time a program is executed.  The
difference between keeping programs in an encrypted state and just
computing signatures on them is that the former actually deters the
spread of a virus, while the latter merely allows you to detect it.

> I am proposing a hierarchical notarization system...

I must assume you are referring to the type of system described
(rather lucidly) in the last issue by William Murray, which
relies upon an already existing network of trusted sources.  I
can see this as viable in some ways.  But I'm not clear on how
it would help the average user who has very few "trusted" sources.
Even software houses have distributed viruses inadvertantly of
late.

>>   ...  Such signatures would be just as easily corrupted as the
>> programs in question.
> Wrong.  Read any recent article on public key cryptography.

Public-key cryptography works fine when you have a method of
distributing the decryption key uncorrupted.  But in the case of
a signature list coming from a bulletin board (for example),
using a public-key method just abstracts the problem one more step.
You STILL need a clean channel for transmitting the decryption key;
else anyone can modify a decrypted version of the signature file,
encrypt it again with another public key set and distribute the
new decryption key with the new signature file.  This is a trivial
step for anyone who actually desires to modify the signature file.
Public-key cryptography is just begging the question.  And once
again, if you have this uncorruptable method for transmitting the
decryption key, you may as well transmit something simpler, like
file size, various checksums and crcs, or the entire program.  It
again boils down to whom you can trust.

- - Jeff Ogata

------------------------------

Date: Mon, 13 Mar 89 16:48 EST
From: "Mark H. Anbinder" <[e-mail]>
Subject: File lock protection?  (Mac)

MacUser magazine reported in the Tip Sheet section of their April
issue that locking individual files using the Locked bit of the Finder
info (using the Locked button in the Get Info window, or a file
utility program) will prevent virus infection.  I don't remember
whether they said "prevent" or "help prevent," so please don't correct
me if I missed a word.

My question -- will this really accomplish anything?  Can any known
viruses infect an application file that has its Locked bit set?

Mark H. Anbinder
Department of Media Services
Cornell University

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest              Friday, 17 Mar 1989         Volume 2 : Issue 65

Today's Topics:
Notification Schemes
The Jitters (dBase IV on PC)
Re: Reply on notarization
nVir2 on the Mac
RE: File lock protection (Mac)

---------------------------------------------------------------------------

Date: Tue, 14 Mar 89 15:38:09 EST
From: Don Alvarez <[e-mail]>
Subject: Notification Schemes

Some further thoughts on the notorization scheme proposed by
[e-mail] (actually motorolla GEG)

Mr. Lambert notes in his rebuttal to the first round of comments that
they were uniformly negative.  Since I was one of the people who
submitted a negative comment, I think I am qualified to comment on
this.  Nowhere in your posting did you provide any details on what
your scheme exactly is.  You gave us a bunch of pointers to government
and internet documents (including the definition of the RSA, as I
recall), and you made your posting from dockmaster, so presumably we
are supposed to accept all this as proof that you know what you are
talking about.  Unfortunately, it backfired.  All you told us is that
you had figured out how to solve all the world's computer security
problems using notarizers, and that if we wanted to know how to do it,
we should read your paper.  No.  There are probably at least a hundred
papers written in the field of computer security every week, and none
of us is going to go to the effort of looking this new one up just
because you can site lots of documents like "(see ISO 7498-2)".  If
you want us to read your paper, tell us about it.  How does your
scheme work?  Walk us through it.  You say that software inherits
notarizing. That's it.  Then you blast what a bunch of other people
have said.  Of course people reacted negatively.  Computer security is
a hard problem, and there is enough nonsense written on the subject
that all ideas are not automatically excepted as being valid.

I started out planning to respond to your responses to peoples
responses to your system, but I realized I had NO IDEA what your
system is.  I went back and re-read your two postings, and realized I
STILL had no idea what you are suggesting.  Perhaps you could take
five minutes and write a short "A does this and then hands it to B who
then computes a checksum and then does that with it.  After this end
users can do Z to their software to test its validity."  I suspect the
letters written to virus-l about your scheme would suddenly become
MUCH more relavent.

Also, I'm curious why you found it necessary to make your postings
from Dockmaster.  If Motorolla isn't willing to hook the people in its
network groups up to the internet, I have a hard time believing that
they understand what networking is all about.  If you can't get
virus-l at work, then that means you can't get email at work, and I
just can't imagine a company hiring a bunch of network specialists and
then not giving them access to the internet.

I would enjoy continuing the discussion of your scheme, since it
sounds like it might be interesting, but PLEASE tell us what your idea
is.

                -Don

     + ----------------------------------------------------------- +
     |   Don Alvarez               MIT Center For Space Research   |
     |   [e-mail]      77 Massachusetts Ave   37-618   |
     |   [phone]            Cambridge, MA 02139             |
     + ----------------------------------------------------------- +

------------------------------

Date:         Tue, 14 Mar 89 16:12:32 EST
From:         Mignon Erixon-Stanford <[e-mail]>
Subject:      The Jitters (dBase IV on PC)

An end user, recently having read about viruses, found some
unexplained, unfamiliar files on his hard disk.  Turns out that
dBase IV has a known bug which leaves untidy file droppings
with extensions of .TMP,  .$ED,  or  .$VM.  When you type them,
you'll see YOUR data.  They're safe to delete without losing data.

Mignon Manin Erixon-Stanford   [yes, the name's for real :-) ]
Smithsonian Institution
Washington, D.C.

------------------------------

Date: Tue, 14 Mar 89 15:10:00 -0800
From: James M Galvin <[e-mail]>
Subject: Re: Reply on notarization

> Public-key cryptography works fine when you have a method of
> distributing the decryption key uncorrupted.  But in the case of
> a signature list coming from a bulletin board (for example),
> using a public-key method just abstracts the problem one more step.
> You STILL need a clean channel for transmitting the decryption key;
> else anyone can modify a decrypted version of the signature file,
> encrypt it again with another public key set and distribute the
> new decryption key with the new signature file.  This is a trivial
> step for anyone who actually desires to modify the signature file.>
> Public-key cryptography is just begging the question.  And once
> again, if you have this uncorruptable method for transmitting the
> decryption key, you may as well transmit something simpler, like
> file size, various checksums and crcs, or the entire program.  It
> again boils down to whom you can trust.

You are confusing two separate issues.  First, there is the use of
cryptographic keys to achieve privacy, authentication and integrity.
Second, there is the distribution and maintenance of those
cryptographic keys.  These are separate and distinct problems, and
need not be considered together.

You seem to be concerned about key distribution, so let me address
that issue.  Consider, if you will, distributing the public half of a
public key set so ubiquitously, that a special distribution channel is
not needed.  This is roughly analogous to giving out your phone
number; if it is not an unlisted number it is easily verified.

Other than that, there are several well-defined protocols for key
distribution.  Check out the OSI Directory Services X.509
Recommendation for the best example.

The bottom line is, key distribution requires a trusted entity.  Once
you trust that entity, you implicitly trust anything it gives you.
You have no choice or the system does not work.  Note, this is no
different than in a "manual" system.  If I do not bump into you
personally and you give you my key, I am trusting someone to give it
to you, i.e., a bonded courier service.

Finally, let me address your comment about "transmitting something
simpler".  It does not work as simply as you suggest.  For example,
many checksums allow blocks of data to be swapped without being
affected.  Thus, file size and most checksums are not appropriate.

As for sending the entire program, the uncorruptable method is
typically prohibitive in terms of cost to use too often.  That is why
encryption is employed in the first place.  The idea is to use the
expensive channel infrequently for the keys and use the keys over
insecure, inexpensive channels to achieve privacy, authentication and
integrity.

Jim

------------------------------

Date: Tue, 14 Mar 89 18:32 PST
From: "Hervey Allen, U of O Comp Ctr [phone]" <[e-mail]>
Subject: nVir2 on the Mac

I'm relatively new to this discussion and I have not seen any
discussion of Macintosh viruses, but I thought I would place my query
here anyway.

Recently the the hard disk we use for our Appleshare network at the
University of Oregon Computing Center was and is infected by a form
of the nVir virus which we have not previously encountered.  We have
numerous public domain virus programs (AntiPan, Interfereon, VirusRX,
VirusDetectve, Ferret, KillScoresUs, AntiVirus, and Vaccine) but none
of them has been able to adequately deal with the strain of nVir we
have encountered.  For those of you who have dealt with Macintosh
viruses before we usually run Interferon on the suspected disk and if
an nVir virus is found we remove it with Anti- pan.  The problem is
that none of these programs was written for this new strain of nVir
which is being called nVir2.

Has anyone out there run into the nVir2 virus? And if so, does anyone
know of a good method for getting rid of it.  The virus will infect
ResEdit and VirusRx if you attempt to run either one with a system
that is already infected.  The symptons of the virus include not
letting a user print, telling the user they do not have enough memory
to open applications, and locking the machine if Vaccine is installed.
The virus appears to be much like the standard nVir virus which
AntiPan can deal with, but more sophisticated so that AntiPan cannot
delete it and VirusRX is immediately infected when run.  We use a
locked disk with a system and the virus utilities when trying to find
and eradicate viruses.

We have been able to get rid of it, but at the expense of removing and
replacing numerous software packages and the System and Finder files
from the System Folder (which includes moving fonts and desk
accessories first).

To us this virus appears completely new.  I apologize in advance if
all of you have already seen this numerous times, but if so please
reply if you have had success in removing this strain of nVir.

Hervey Allen

Consultant
University of Oregon Academic Computing Center
Eugene, Oregon   97403

------------------------------

Date:         Tue, 14 Mar 89 14:27:30 EST
From:         Joe Simpson <[e-mail]>
Subject:      RE: File lock protection (Mac)

Set the file locked bit will prevent a virus from using the high level
write routines to change the file.

This "ups the anti" and makes a virus that can defeate this protection
more expensive to write.

Most anti-virus techniques fall into this category.  That is, you
make the virus writer work harder to infect your system.

To write to the locked file the virus writer on the Mac would probably
have to use low level routines and do sector read/writes with manual
update of the catalog.

Joe McMahon (bless his heart) has assembled a very nice virus
protection distribution service.  TELL LISTSERV at SCFVM INDEX PUBLIC
to see the catalog.  I should note that this service covers Macintosh
only.

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest              Friday, 17 Mar 1989         Volume 2 : Issue 66

Today's Topics:
re: Virus hysteria.
overprotection, lowercase VM filenames, corporate espionage
Re: File lock protection?  (Mac)
Virus Publicity & the Media
Re: File lock protection?  (Mac)
notarization
New virus (PC)
nVIR infection on MAC

---------------------------------------------------------------------------

Date: Tue, 14 Mar 89 15:07 EST
From: Eric Thies <[e-mail]>
Subject: re: Virus hysteria.

>Date:     Mon, 13 Mar 89 08:40 EST
>From:     Cincinnati Bengals. <[e-mail]>
>Subject:  Virus hysteria.
>
>     I was wondering if anyone has comments on the way reports of
>viruses seem to be given too much attention by the media.  As an
[...]
>Surely this is newsworthy, but front page?  This seems comparable to
>placing reports on the front page every time the common cold breaks
>out on campus.  Comments?

Yeah.  We got about the same reaction a while back when we had a few
problems with a virus.  And about a week later, the internet virus
hit.  The papers sort of lumped everything together; one even claimed
that we had 25 or so computers hit by the internet virus.  Actually we
had 25 or so floppy disks hit by the PC virus and weren't touched by
the internet virus (we aren't on the internet (yet) :-)

I get the feeling that computer viruses are the new boogie man.  For
most people, computers are these big, mysterious things which sort of
'control' things...and the idea that these viruses can 'destroy
everything' is terribly frightening to most.  This parallels the fear
that the word Communist used to (and for some still does) invoke.

Something that most don't know much about and that can destroy
everything...  something we can't control...since it has
control...makes us feel HELPLESS.  The media love to pick up on things
that scare the hell out of folks...fear and sex sell.  Just wait for a
virus that draws sexy pictures...:-)

>Tom Kummer

- -eric
++==++==++==++==++==++==++==++==++==++=++==++==++==++==++==++==++==++==++
Eric Thies, Systems                    [e-mail]
Academic Computer Center               [e-mail]
Univ. of N. Carolina at Greensboro     [e-mail]
Greensboro, NC 27412-5001  Tel: [phone]   "Peace, love, waterbed."
++==++==++==++==++==++==++==++==++==++==++==++==+==++==++==++==++==++==++

------------------------------

Date:         Wed, 15 Mar 89 04:22:11 EST
From:         Steve <[e-mail]>
Subject:      overprotection, lowercase VM filenames, corporate espionage

I just wanted to comment on some things:

   Reed Rector suggests that he'd be willing to pay more for a program
that incorporated some kind of anti-viral or virus-detection feature.  I
wouldn't.  First of all, I am very picky and have enough trouble finding
software that has precisely the features I want, so I could care less
about an added new-fangled and probably ineffective anti-viral feature.
Second, I rarely come across viruses (none so far that I know of.  In
fact I don't think I even know anybody who has actually seen a virus.
Yes, I got a copy of CHRISTMA EXEC, but I wasn't stupid enough to run
it...).  Second, I prefer to protect myself by keeping backup copies of
things I care about (on write-locked diskettes); this is also good
protection against the most common problem I encounter: corrupted
portions of a disk (NOT due to a virus or the like, but instead due to
a bad or marginal sector, or a program that doesn't check to see that
you haven't switched diskettes before it writes).  Sophisticated file
encryption schemes would waste my time (but it wouldn't hurt to have
checksums somewhere so I could check the integrity of my files should I
ever suspect viral activity).  I am in agreement with what Don Alvarez
said so very well about all this a few months ago.

   Bruce Ide mentions a program that changes all your (VM) filenames to
lowercase on an IBM mainframe system.  I encountered lowercase
filenames by accident initially (created by one of my own programs).
I now have EXECs which rename mixed-case filenames to or from uppercase.
This sort of thing is really not a problem.  And there's always VMBACKUP
(automatic backups) if one finds a few files missing...

   Joe Sieczkowski raises the very interesting issue of a company
patching a trapdoor into a competitor's computer.  I would think that no
company would be willing to risk their reputation on such an escapade.
The secret would very likely come out eventually (or even serve very well
as blackmail material for a disgruntled systems programmer).  However...

Steve Woronick         | Disclaimer:  Always check it out for yourself...
Physics Dept.          |
SUNY at                |
Stony Brook, NY  11794 |
Acknowledge-To: <XRAYSROK@SBCCVM>

------------------------------

Date:     Wed, 15 Mar 89 09:10 EST
From:     "Brian D. McMahon" <[e-mail]>
Subject:  Re: File lock protection?  (Mac)

>MacUser magazine reported in the Tip Sheet section of their April
>issue that locking individual files using the Locked bit of the Finder
>info (using the Locked button in the Get Info window, or a file
>utility program) will prevent virus infection.
[ . . . ]
>My question -- will this really accomplish anything?  Can any known
>viruses infect an application file that has its Locked bit set?

No.  A file that has been locked by software can also be *unlocked* by
software.  On the Mac, this is darn near trivial -- I think it would
be a matter of only a few bytes of code in the virus, to call the
appropriate unlocking routine.  (Where is my _Inside Macintosh_ when I
need it?)  While I don't know for certain whether any of the known
nasties actually do this, relying on software locks is definitely
unsafe.

>Mark H. Anbinder
>Department of Media Services
>Cornell University

Brian McMahon    <BRIAN@UC780>
Administrative Computing
University of Maryland University College

------------------------------

Date:     Wed, 15 Mar 89 09:02 MDT
From:     "Craig M." <[e-mail]>
Subject:  Virus Publicity & the Media

I agree with Tom Kummer--I think there is too much "sensationalizing"
of a virus outbreak.  An even more obvious example than the front-page
newspaper article is our University of Utah's Mac outbreak.  It not
only hit the Deseret News and Salt Lake Tribune (although not front
page), all three network station carriers reported it on the evening
news.  It also hit a cable news station, but it was later at night.

They must think that something like this is outstanding and will
capture more-than-normal public attention; I can't imagine what else
it could be.

------------------------------

From: Danny Schwendener <[e-mail]>
Subject: Re: File lock protection?  (Mac)

>MacUser magazine reported in the Tip Sheet section of their April
>issue that locking individual files using the Locked bit of the Finder
>info (using the Locked button in the Get Info window, or a file
>utility program) will prevent virus infection.

All currently known viruses will fail to infect a file if the latter
is locked. All viruses (current and future) will fail if the *disk*
the file is on is locked. The difference is that locking a file merely
causes a bit in the file information to be changed, while
(hardware-)locking a disk physically disables all write-accesses to
the volume.

Software-locking of files or volumes may be bypassed, albeit not
easily. Moreover, some applications, which save their settings in the
data fork or in a resource within the application file, won't work
correctly if they have been previously locked. So it is not a good
idea to rely on software-locking as only protection against viruses.

- -- Danny Schwendener
   ETH Macintosh Support

------------------------------

Date:  Thu, 16 Mar 89 08:55 EST
From:  [e-mail]
Subject:  notarization

>You STILL need a clean channel for transmitting the decryption key;
>else anyone can modify a decrypted version of the signature file,
>encrypt it again with another public key set and distribute the
>new decryption key with the new signature file.  This is a trivial
>step for anyone who actually desires to modify the signature file.
>Public-key cryptography is just begging the question.

Not true.  All signatures for a hierarchical notarization system
would be verifiable to a single primary authority.  The ONLY
trusted distribution required for the system would be the
public certificate of the "root" certification authority.

The following illustration should clarify this proposal.

Pa      is the public certificate of authority "A"
Sa(Pb)  is the public certificate of "B" signed by "A"

                                   Pa
                             |
                   -------------------
                   |                  |
                   | Sa(Pb)           | Sa(Pc)
              ------------       ------------
              |          |       |          |
              |          |       |          |
             Sb(Pd)     Sb(Pe)  Sc(Pf)     Sc(Pg)

A more formal description  can be found in ISO DIS 9594-8
where ASN.1 is used to define a certificate as:

Certificate  ::= SIGNED SEQUENCE {
        signature             AlgorithmIdentifer,
        issuer                Name,
        validity              Validity,  -- a time period
        subject               Name,
        subjectPublicKeyInfo  SubjectPublicKeyInfo}

The important part of this certificate defintion is
that the certification authority (CA) binds the
subjects name, the subjects public information,
and the certification authorites name (issuer) together
with a digital signature.

Extending the definitions in 9594-8 for the notarization of files
a posible "dataseal" would be:

DataSeal  ::= SIGNED SEQUENCE {
        filename              OCTET STRING,
        filelength            INTEGER,
        algid                 AlgorithmIdentifer,
        issuer                Name,
        filehashvalue         ENCRYPTED OCTET STRING
                              -- where the octet string is the
                              -- result of the hashing of
                              -- data in 'filename'
        }

The definition above would allow the sealed data, the "dataseal"
and the certificates to be distributed separatly.


Paul A. Lambert                  Motorola GEG, Secure Network Section
Lambert -at docmaster.ncsc.mil   8201 E. McDowell
[phone]                   Scottsdale, Az. 85252

------------------------------

Date: Thu Mar 16 09:16:13 1989
From: utoday![e-mail]
Subject: New virus (PC)

Just a quick note on a relatively new virus, and a "directed" virus at
that:

One of my larger clients called me in because they discovered that
some of their dBase files were corrupt. Wanted me to fix them up.
When I got there, I discovered that a database file (all have .DBF
extensions) worked on machine A, but when the files were copied to
floppy, they didn't work on machine B.  But they would work on a
machine which had Machine A's copy of DBASE brought over to it.

Upon investigation, I discovered a small TSR virus on Machine A.  It
had infected the DBASE program which was later run on MAchine C, hence
why it worked there.

The virus, after spreading to all .COM and .EXE files in the current
directory, would look for an open operation on a .DBF file.  All
writes to the file would have two bytes transposed at random. These
bytes' offsets were stored in a file called "BUG.DAT" (a hidden file)
in the .DBF's directory.  Subsequent reads of this data would cause
the transposition of the same data, and everything would look nifty.
After this code had run for 90 days (after the BUG.DAT file was 90
days old), it would trash the disk (eat the FAT and root directory).

Getting rid of the virus wasn't difficult: just copy in new
executables from your backup.  However! If you did this, your data is
history - nothing to transpose it back into "real" form.  What I did
was to debug the heck out of the virus, find the *write* transposition
and null it out, then read each corrupted data file and write it back
out.  Look for the sequence
   "MOV  AL, ds:[bx+si]
    MOV  AH, ds:[dx+di]
    XCHG AH, AL
    MOV  ds:[bx+si], al
    MOV  ds:[bx+di], ah"

and either null out the XCHG operation or all of the above.  This
effectively will remove the transposition only only on the write (for
some reason, the reverse transposition on the read used substantially
different code).

After nulling it out, simply use the infected DBASE program to read
all the corrputed files and to write them back out to a new file.
Viola! Now, copy over the infected code with your backup copy of the
executable and things should work out well.

Since this is a TSR virus, make sure to do a boot operation after
you've done the "repair" on the DBASE program.  Obviously, you'll have
to disinfect all the other programs on your disk as well.  Look for
the sequence "ssi" at offset location 7. If found, you've found an
infected file.

The scary part: if you're infected and just remove the infection, your
data becomes worthless.

I've only seen this virus at one site so far.

Ross M. Greenberg
UNIX TODAY!             594 Third Avenue   New York   New York  10016
Review Editor           Voice:(212)-889-6431  BBS:(212)-889-6438
uunet!utoday!greenber   BIX: greenber  MCI: greenber   PCMagNet: 72241,36

------------------------------

Date: 17 March 1989, 01:30:05 ECT
From: Anders Christensen   [phone] <[e-mail]>
Subject: nVIR infection on MAC

Some users at our university claim that their Macintoshes have been
infected by nVIR after they inserted and then removed an infected
diskette, without executing any program on (or booting from) the
infected diskette.

One of the users claims this happened:
   - He booted from a writeprotected 'clean' original diskette
   - He formated the harddisk, and moved the system and some other
        software there (all writeprotected and 'clean')
   - He then tested the system with VirusDetective and Interferon
        without getting any warnings
   - Then he inserted an infected diskette, and removed it immediately
        without running any program
   - He then ran VirusDetective and Interferon and got a message that
        the harddisk has been infected by nVIR.

The above would be possible if the Mac loaded executable code from the
diskette into memory and started executing it whenever a diskette is
inserted. Is there any Mac-Wizard who can tell me if Macs behave like
this or not?

Anders Christensen
User Consultant
Computer Center (RUNIT-D)
Norwegian Institute of Technology

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest              Monday, 20 Mar 1989         Volume 2 : Issue 67

Today's Topics:
A New VIRUS Conference
(Mac) nVIR by Association
Re: nVIR2 (??) (Mac)
I need help with viruses (Mac)
File lock protection (Mac)
nVir2 on the Mac
Viruses in media

---------------------------------------------------------------------------

Date:    Fri, 17 Mar 89 07:46 CST
From:    Ken  De Cruyenaere <[e-mail]> 204-474-8340
Subject: A New VIRUS Conference

   The Computer Security Institute has put together a pretty interesting
   sounding conference in early May.  Details follow:

           COMPUTER VIRUSES '89 at the IBM & DEC Users Conference
               May 1-3, 1989 * Hyatt Regency O'Hare * Chicago
                  Sponsored by Computer Security Institute

                              PROGRAM OVERVIEW

* Partial list of speakers addressing virus-related topics:

     Eugene H. Spafford, Purdue University, will present an in-depth
          analysis of the Internet worm incident.

     Michael Karels, head of UNIX development at UC Berkeley and an
          Internet worm "swat team" member, will discuss how UNIX is
          meeting the virus challenge.

     Kenneth R. van Wyk, creator of Lehigh University's VIRUS-L bulletin
          board, who led the fight against the Lehigh virus, will talk
          about lessons learned.

     Richard D. Pethia, Carnegie Mellon University, will describe the
          first DARPA CERT (Computer Emergency Response Team), which he
          heads.

     Davis McCown, prosecutor in the "Texas Virus Trial" which
          convicted Donald Gene Burleson in September 1988, will
          recount the investigation, the trial, and what was learned.

- -----------------------------------------------------------------------------
* "Live" demonstrations of viruses, hacking, bulletin boards:

     Ross Greenberg, author of FLU_SHOT+, will demo viruses and describe
          PC Magazine's evaluation of 11 anti-virus products.

     Thomas V. Sobczak of Application Configured Computers will
          demonstrate hacking, underground bulletin boards, virus
          behavior, and public domain solutions.

     John McAfee, Computer Virus Industry Association, will demonstrate
          virus and anti-virus programs and present new statistical
          information on viruses.

- -----------------------------------------------------------------------------
* Information on new security-related products:

     CA-ACF2/VAX and CA-Top Secret/VAX, which can help unify security and
          access control in mixed IBM-DEC shops.

     ClydeSentry, LJK/Security, Secure Pak, and The Security Toolkit,
          for assessing and monitoring security in DEC environments.

- -----------------------------------------------------------------------------
* Exhibition -- A wide range of computer security products will be
displayed during this two-day show.

* Workshop Orientation -- 42 half-day sessions

* Discounts:  40% air travel discounts with United
             35-40% discount on Hyatt Regency O'Hare room rates


For more information, Contact:
                   Van McGuirk
                   Computer Security Institute
                   360 Church Street
                   Northborough, MA 01532
                   [phone]
- ---------------------------------------------------------------------
Ken De Cruyenaere - Computer Security Coordinator
Computer Services - University of Manitoba - Winnipeg, Manitoba, Canada
Bitnet: [e-mail]               [phone]

------------------------------

Date:         Fri, 17 Mar 89 09:17:08 EST
From:         Joe McMahon <[e-mail]>
Subject:      (Mac) nVIR by Association

The nVIR virus must be executed in SOME way for it to infect a system.
Inserting a disk causes SYSTEM code to be executed, but none from the
inserted disk. I suggest you track this person down, and have him/her
do it again, with you watching. See if there are any funky INITs or
suchlike that s/he's using.

  --- Joe M.

------------------------------

Date:     Fri, 17 Mar 89 12:20:05 PST
From:     [e-mail]  (Commander Spock)
Subject:  Re: nVIR2 (??) (Mac)

Chances are you have nVIR, Type B, and someone who has a cute sense of
humor has simply renamed the resource ID.  If you can afford to spend
about $70, go out to a retail store and purchase a copy of "Virex" by
HJC Software.  It should alleviate the problem.

Hope this helps!

Robert S. Radvanovsky      [e-mail] (Internet)
California Polytechnic Univ. [e-mail]                 (BITNET)
Pomona, California

P.S. Any questions?  Send them to me!  I'll try to help you as much as
possible.

------------------------------

Date:    Fri, 17 Mar 89 18:07 EST
From:    "Sonja Kueppers [phone]" <[e-mail]>
Subject: I need help with viruses (Mac)

I am a lowly student employee of the Center for Academic Computing at
Penn State University, and I need help in convincing my bosses that it
is NOT necessary to add any other search strings to Virus Detective
2.1.1.  Everyone here seems convinced that search strings like DATA ID
- -4001 and atpl ID 128, both of which are redundant to CODE JStart 7026
for our purposes-all we are trying to do is find the viruses anywhere
on the system disk so that we know to recopy the disk.

If you have any information which would help me convince my bosses of
this, please send it to me!  Thanks!
- -Sonja

------------------------------

Date: Sat, 18 Mar 89 13:56:48 EST
From: [e-mail] (Joe Sieczkowski)
Subject: File lock protection (Mac)


>Set the file locked bit will prevent a virus from using the high level
>write routines to change the file.
>...
>To write to the locked file the virus writer on the Mac would probably
>have to use low level routines and do sector read/writes with manual
>update of the catalog.

I'm no MAC expert but I don't even think low level routines are necessary.
ie,
  if file locked then
      unlock file
      infect/change file
      lock file
  else
      infect/change file

Joe

------------------------------

Date: 18 Mar 89 20:37 +0100
From: Markus Mueller <[e-mail]>
Subject: nVir2 on the Mac

> is infected by a form
> of the nVir virus which we have not previously encountered.  We have
> numerous public domain virus programs (AntiPan, Interfereon, VirusRX,
> VirusDetectve, Ferret, KillScoresUs, AntiVirus, and Vaccine) but none
> of them has been able to adequately deal with the strain of nVir we

Looks like the same strain of nVIR that we have seen a couple of times
at ETH Zurich. Unlike the regular vNIR, this strain does not maintain
an nVIR 2 resource but hides that information somewhere else, causing
all disinfection programs to fail. The only way to get rid of this
nVIR strain is to reload all infected applications from clean copies.

   Markus Mueller
   Communications Systems Group
   Eidgenoessische Technische Hochschule
   CH-8092 Zurich
   Switzerland

   Switch : [e-mail]
   ARPA   : [e-mail]
   UUCP   : [e-mail]
   X.400  : G=markus;S=mueller;OU=inf;O=ethz;P=ethz;A=arcom;C=ch

------------------------------

Date:     Sat, 18 Mar 89 17:42 EST
From:     Dimitri Vulis <[e-mail]>
Subject:  Viruses in media

Reprinted without permission from _The Office: Magazine of Information
Systems and Management_, March 1988. I have omitted about 50% of the
paper (that was not false and/or misleading):

>                The Computer Virus: is There a Real Panacea?
>
>What first began as a prank has since reached the point where everyone
>has cause to worry.
>
>                             By Scott W. Cullen
>
>You are sitting at your computer, working on an important report.
>Suddenly, the information on screen disappears and is replaced by the
>word ``Goodbye.''  Within seconds, this message vanishes from your
>view. You try to retrieve data only to discover it is gone, along with
>all the other files stored on that disk. You have just been attacked
>by a computer virus, and you are not alone.  It is estimated that
>nearly 350,000 computers were infected by some type of virus last
>year.

The introduction, and the accompanying cartoon, are a rip-off of the
Time magazine article.

>...
>
>A virus is a self-replicating block of code that enters a computer via
>diskette, over telephone lines, or manually. The one characteristic of
>a virus that distinguishes it from other codes is that it spreads the
>infection just as humans spread a biological virus---by contact. As
>healthy diskettes and programs come in contact with the disk drive of
>an infected computer, the virus, in the form of a format code, merges
>into that disk causing an infection.

A meaningless use of buzzwords.

>According to Jon David, a Tappan, N.Y.-based computer consultant,
>``Viruses usually affect specific operating environments. When those
>environments change, a virus may act differently. It may pose no
>danger in one but wreak havoc in another.''
>
>A virus may destroy data, reformat a disk, weak out its drive, or
>flash a harmless message on screen. ``The most insidious problem is a
>virus that spreads itself and causes occasional errors,'' says Larry
>DeMartin, president of Computer Integrity Corp.
>
>Many viruses are self-replicating, often consuming significant space
>in a computer's memory and eventually jamming the machine. Even
>computers utilizing voice synthesizers have been stricken with audible
>disturbances. A virus not only affects PCs; it can attack mainframes
>and minicomputers.

That is, the same virus infects PCs, minis and mainframes?

>Most viruses have what is described as a Trojan Horse feature or
>trigger that instructs it to act at a predetermined time or event such
>as a specific number of program executions. This may happen the same
>day or years later.

That's not what I mean by a Trojan horse...

>...
>
>The first virus was created in the 1960s as a game. Kept secret for
>nearly 20 years, the formula was reveled in a 1983 speech by Ken
>Thompson, a software engineer who wrote the first version of the Unix
>computer operating system.  One year later, a columnist for a
>scientific journal mailed readers, who sent in a $2 postage fee,
>guidelines for creating their own viruses. Since that time, malicious
>hackers have been hovering over keyboards honing unhealthy programs.

I don't think I have to comment on this...

>One of the first destructive viruses to gain notoriety was the
>``Pakistani Virus,'' which first appeared in early 1986. Created by a
>computer store owner in Lahore, Pakistan, as retribution against users
>who made illegal copies of his customized programs, the virus was
>inserted in brand-name software and later sold to American tourists.
>Because these customers often exchanged disks or made bootleg copies
>for friends, the virus spread to nearly 100,000 floppy disks, often
>wiping out data.

I don't know where the number came from. The story differs
significantly from what has been reported by others.

>...
>
>The media blitz following the November 1988 epidemic affecting users
>of the low-security InterNet message exchange network turned a hacker
>into a celebrity and spawned a score of imitators. Some of these
>hackers even broke into the same network less than a month after the
>earlier incident. Apparently network users were circulating
>information on methods to prevent unauthorized access, and
>inadvertently tipped off hackers to the formula for plugging into
>unprotected networks.
>
>Shared information networks such a InterNet are designed for easy
>access and are more susceptible to a virus that those providing
>sensitive information.  Even though these networks are harder to
>penetrate because of the complex series of access codes or passwords,
>computer experts believe that no system or network is virus-proof.
>``There is always an entry point, even in a diskless system with no
>outside connection,'' explains Del Jones, president, National LAN
>Laboratory...

No comment.

>...
>
>Computer security methods vary. Perhaps the most drastic is turning
>off a machine and leaving it off. Another alternative is disconnecting
>it from telephone lines. Securing operations by restricting or
>monitoring computers and their facilities access is a more reasonable
>means of protection which many organizations have adopted. ``Companies
>are not afraid of virus attack, but of using system use,'' said Mr.
>David.
>
>An infected computer can be costly. According to the Computer Virus
>Industry Assn., an organization made up of software manufacturers who
>make anti-virus products, the cost to clean up last November's
>InterNet virus was estimated at about $96 million. Of 50,000 possible
>computers, 6200 were infected and shut down for nearly 16 hours. The
>group says it took an average of 12 programmers at each site some 36
>hours to evaluate every compute that may have been infected. The cost
>of each immobilized computer was put at $372 per hour, the association
>reported.

Somebody ought to do something about this CVIA. As far as I know, 6000
was a very rough estimate. All these exact numbers look very
suspicious.

>...
>
>The past five months have seen heavy interest in anti-viral products.
>After last year's highly-publicized incident, manufacturers of these
>programs experiences as much as a 50% sales increase.
>
>Some 30 products are available, ranging from detective programs which
>screen software for viruses, to recovery/corrective products which
>help a system recover from a virus attack by purging it. These
>programs cost from $10 to several hundred dollars.

That's unfortunate, since most of them are worthless/harmful.

>...
>
>Some programs require users to boot-up once in the morning, others
>require this more frequently. ``The more checking you do, the more
>secure you are,'' said Mr. David, ''and if you get protection that
>costs five minutes of time in the morning, it's worth it.''
>
>According to Mr. DeMartin, programs used the most often should be
>checked frequently. One such product checks for any program
>modification and also indicates direct human tampering, hard disk
>errors and operating system failures. Mr. DeMartin believes that a
>virus deserves its own protection mechanism because all previous
>computer diseases could be cured by yesterdays back-up tape.

Again, meaningless use of buzzwords.

>...
>
>                Sidebar: How to Reduce the Risk of Infection
>
>All software should be purchased from known, reputable sources and be
>in its original shrink-wrap or sealed diskette containers when
>received.
>
>New software should be reviewed carefully by a system manager and
>quarantined on an isolated computer before installation on a
>distributed system. This will reduce the risk of contamination.
>
>A back-up copy of software and data should be made at least one a
>month, with the back-up copy stored for at least one year before
>reuse. This will allow restoration of a system that has been
>contaminated by a ``time-released'' virus. A plan that includes
>``grandfathered'' rotation of back-up copies will further reduce risk.
>
>System administrators should restrict access to programs and data on a
>``need-to-use'' basis. This isolates problems and facilitates
>diagnosis.
>
>Many ``shareware'' and ``freeware'' programs are invaluable
>applications.  However, they are the prime entry point for system
>viruses. Skeptical review of such programs is prudent. Also, extended
>preliminary quarantine is essential before introducing these programs
>on a distributed system
>
>System managers should make plans for quick removal from service of
>all copies of a suspect program, and immediately back up all related
>data. These plans should be made known to users.

Meaningless buzzwords; apparently, this refers to networks rather than
PCs.

I am not aware of any reliable statistics comparing the number of
virus infections via shrink-wrapped software with that via software
downloaded from bulletin boards. My personal estimate is that a
shrink-wrapped disk, especially one from a large, badly managed
company, is approximately 3 times as likely to be infected with a
virus than a program picked at random from a reputable BBS.

- -DV

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest             Tuesday, 21 Mar 1989         Volume 2 : Issue 68

Today's Topics:
proposed comp.virus newsgroup
Viruses and Media
nVIR without execution of code? (Mac)
POSSIBLE TROJAN HORSE (Mac)
Virus Writer Obituary

---------------------------------------------------------------------------

From:       David.J.Ferbrache <[e-mail]>
Date:       Mon, 20 Mar 89 13:32:32 GMT
Subject:    proposed comp.virus newsgroup

As I am sure those of you with access to USENET news are aware, there
is currently a discussion under way concerning the formation of a new
newsgroup comp.virus. Hopefully the newgroup will be a useful addition
to the virus-l mailing list (with which it will be gatewayed). Through
the creation of this newsgroup (which Jim Wright is organising), we
can increase the level of knowledge of a major part of the community
about the dangers of viruses and the measures we can take to control
the spread of this menace.

I enclose a copy of an article I posted to news.groups, in response to
a variety of initial comments to the posting. Anyone with any comments
please let Jim have them at [e-mail], or post
them to the newsgroup news.groups. The discussion period is due to end
in about a week, after which there will be a fortnight during which
the usenet community will vote on the creation of the group.

anyway, to give you a flavour of the discussions under way:


To answer a few points concerning the comp.virus discussion underway
at the moment,

1. There is a need for comp.virus which misc.security cannot satisfy. The
   later group is a general discussion forum ranging from Lockpicking to
   data integrity. Comp.Virus seeks to address one specific area of computer
   security, namely viruses and other self-replicating programs.

   By restricting the group specifically to this topic we hope to provide
   a useful, informed, technical forum providing details of new virus
   threats; disinfection software; advice on general precautions against
   viruses and discussion on the social impliations of computer viruses.

   Computer viruses can directly affect the owners of any of the more
   popular PCs (IBM, Mac, Apple II, Atari ST and Commodore Amiga). To
   alleviate this growing problem it is vital that the every owner is
   aware of the very real problem of viruses together with the measures
   s/he can take to disinfect the system.

   Many micro owners are interested in viruses but not in all aspects of
   computer security.

2. The newsgroup has the potential to help virus-l (the bitnet mailing
   list) reach a far larger audience, with the dual benefit of increasing
   the level of knowledge of the community, and (very importantly)
   reducing the delay between discovery of a new virus strain and its
   reporting to the groups active in developing disinfection software.

3. This proposal was not made in isolation. Much discussion too place before
   hand. The group will be gatewayed to virus-l, it will be supported by
   a network of software archive sites, it will receive regular summaries
   for new members of known viruses, disinfection software and archive sites.

4. The problem of viruses is not machine specific. While individual virus
   strains and the associated anti-viral software is machine specific, there
   are many aspects of viruses which are not. Witness the excellent series
   of articles published on the comp.sys groups dealing with the operational
   principles of viruses, and the associated discussion on the ethics of
   releasing such information (also the discussion that ensued when I posted
   my original request for information on viruses). Low level DOS viruses
   do share much in common between the IBM, Atari, Amiga and Apple. Techniques
   that operate on one machine can be adapted for the others.

In summary,

Much thought has gone into this proposal. There is both a need and a demand
for this group (as I hope the vote will show). A news group will bring timely
information on new viruses to the whole community, and hopefully help us to
reduce the threat.

Thanks for your time.

- ----------------------------------------------------------------------------
Dave Ferbrache                            Personal mail to:
Dept of computer science                  Internet <[e-mail]>
Heriot-Watt University                    Janet    <[e-mail]>
79 Grassmarket                            UUCP     ..!mcvax!hwcs!davidf
Edinburgh,UK. EH1 2HJ                     Tel      (UK) 031-225-6465 ext 553

------------------------------

Date: 20 March 1989, 14:26:47 CDT
From: Nicholas Geovanis         312-996-0590         UWC6NTG  at UICVMC
Subject: Viruses and Media

   Dimitris Vulis correctly attacks the media for inadequate and
misinformed virus reporting. I'm not trying to stray from the subject
of this list, but I'd like to mention that, after reading a recent U.S
News and World Report, I was shocked by the low quality of the
reporting and the mindless over-simplification of issues and events.
   This is not a problem confined to their reporting of technical
issues. If factual reporting of international events is beyond their
desire or capability, then it's no wonder that they stumble over
technology. Unfortunately, since technology plays an increasingly
important role in American society, our citizens are destined to be
uninformed and misinformed here also.
                               NickGeovanis-SysProg-AdminCompCtr
                               UnivIllinois-Chicago
                               UWC6NTG at UICVMC

------------------------------

From: Mitchell Perilstein <[e-mail]>
Date: Mon, 20 Mar 89 15:46:37 EST
Subject: nVIR without execution of code? (Mac)

    In reference to Anders Christensen's message about witnessing
an nVIR infection by inserting an infected floppy to a clean machine
and immediately removing it, I would like to add two thoughts.

    One is that the nVIR sourcecode was widely posted to European
bulletin boards, so a new strain that patched a system to respond to
DiskInsert events wouldn't be unreasonable.

    Second, it may be possible Apple distributed some nVIR by
accident.  My friend's new SE recently was infected with the nVIR
virus, and we are fairly certain it was introduced to the machine via
the "Teach Text" application on the System Tools diskette packaged
with the machine.  The diskette was used to format the SE's new drive,
then it was put away and never again touched. Later, when nVIR was
found, all my friend's floppies were examined, and the Tools disk,
still locked, had the normal nVIR strain in that one application.

    I emailed to someone at Apple a question about the possibility
of this happening, complete with disk serial numbers. They replied
that they had done some checking and found nothing, and suggested I
see if the machine's dealer had possibly used the diskettes. I trust
Apple on this -- their business depends upon it.

Mitchell N. Perilstein
 usenet: {decvax,sun}!cwjcc!alpha!mitch
 arpa:   [e-mail]

------------------------------

Date: Mon, 20 Mar 89 12:05:31 PST
From: [e-mail] (Rollo D. Rogers)
Subject: POSSIBLE TROJAN HORSE (Mac)

Date: 19 Mar 89 01:21:46 GMT
From: [e-mail] (BMUG)
Newsgroups: comp.sys.mac
Subject: Trojan Horse Warning

WARNING: We have discovered the existence of a "Trojan Horse" in a
bogus upgrade to Anti-Toxin, a virus-detecting INIT from Mainstay.
The INIT, labelled as version 2.0 in the Get Info box, attempts to
format your disk and rename it "Scored!".

A couple variations of this INIT have been reported. The one we have
seen has a size of 2,276 bytes, created Fri, Jan 13, 1989, 3:05PM, and
modified Mon, Mar 6,1989, 12:03AM. A quick inspection of the
disassembled code of the INIT indicates that it does nothing until the
clock time on your mac is after Mar 13, 1989, 5:20PM. The perpetrator
obviously wanted the Trojan Horse to lie dormant for a few days,
giving it a chance to spread to more users.

Although I believe Anti-Toxin is a commercial product, this bogus
version has apparently been uploaded to several bulletin boards.
Watch out!
                                                             /\
BMUG                      ARPA: [e-mail]    A__A
1442A Walnut St., #62     BITNET: bmug@ucbgarnet            |()|
Berkeley, CA  94709                                         |  |
[phone]                                              |  |
- -------

- -------

------------------------------

Date:     MON MAR 20, 1989 21.48.07 EST
From:     "David A. Bader" <[e-mail]>
Subject:  Virus Writer Obituary

Copied from the Globe-Times (Bethlehem, Pa), March 17, 1989:

Jim Hauser, 39, made first computer virus

SAN LUIS OBISPO, Calif. (AP) -
Jim Hauser, who took credit for creating the first computer virus,
was found dead Tuesday at age 39.
  Deputy Coroner Ray Connelly said Hauser died following an aneurysm
of the brain suffered Sunday night or Monday morning.
  Hauser said he and one of his students developed the first computer
virus in 1982 for the Apple ][ computer, designing it to give users a
"guided tour" of the computer's internal programming.  Although his
program was harmless, he saw the potentially destructive capability of
what he also called an "electric hitchhiker" that could attach itself
to computer programs.

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest             Tuesday, 21 Mar 1989         Volume 2 : Issue 69

Today's Topics:
Hard Drive Protection from nVir Virus (Mac)
Re: nVIR at Apple (Mac)
Viruses and the Media

---------------------------------------------------------------------------

Date: Tue, 21 Mar 89 08:52 EST
From: [e-mail]
Subject: Hard Drive Protection from nVir Virus (Mac)

I am a new subscriber to the Virus-L list.  I subscribed in hopes that
someone could possibly give me some information or advice.  I need to
find a hard drive write protection tool.  This is my problem - my macs
were infected with the nVir virus. After extensive cleanup and losing
a lot of good applications I placed the Vaccine into my system files.
It has been brought to my attention that the users either Turn Off the
protection or remove the vaccine so they may be able to use their
infected applications.  What can I do in this situation.  This campus
is new to macs and I have only worked with them for about a year.
This has become very frustratinng.  Can someone help?

------------------------------

Date: Tue, 21 Mar 1989 07:00:23 PDT
From: [e-mail] (Brian Bechtel)
Subject: Re: nVIR at Apple (Mac)

In article <[e-mail]> "Mitchell N. Perilstein"
<[e-mail]> writes:
>     In reference to Anders Christensen's message about witnessing
> an nVIR infection by inserting an infected floppy to a clean machine
> and immediately removing it, I would like to add two thoughts.
>
>     One is that the nVIR sourcecode was widely posted to European
> bulletin boards, so a new strain that patched a system to respond to
> DiskInsert events wouldn't be unreasonable.

However, this would assume that the system is already infected.  When
a disk is inserted, no code is executed from the disk in question.
System code, already in place from the current booted system, is
executed.  There is no method for a floppy disk to infect a system
merely by being inserted into the machine.

>     Second, it may be possible Apple distributed some nVIR by
> accident.  My friend's new SE recently was infected with the nVIR
> virus, and we are fairly certain it was introduced to the machine via
> the "Teach Text" application on the System Tools diskette packaged
> with the machine.  The diskette was used to format the SE's new drive,
> then it was put away and never again touched. Later, when nVIR was
> found, all my friend's floppies were examined, and the Tools disk,
> still locked, had the normal nVIR strain in that one application.
>
>     I emailed to someone at Apple a question about the possibility
> of this happening, complete with disk serial numbers. They replied
> that they had done some checking and found nothing, and suggested I
> see if the machine's dealer had possibly used the diskettes. I trust
> Apple on this -- their business depends upon it.

Okay, the following is based on my personal experiences here at Apple:

I don't know to whom the message referenced above was mailed, but I
can assure you that the possibility of Apple shipping any software
with a Virus is almost nonexistant.  We have a group whose sole
responsibility is to ensure the clean build of our software.  This
Software Configuration Management (SCM) group has implemented a
variety of strategies to help ensure a sterile environment:

1) All build machines are not connected to any network.
2) All software is built from source files that have been stripped of all
resource forks.
3) All software is built from source files.  No software is allowed to be
submitted with pre-existing resources.
4) All software is built using tools created here at Apple.  This means
that we build the tools, as well as the software.  The tools are built
using the same procedures as any other software.
5) All software is checked after build using a variety of tools such as
VirusRx and ResEdit.  The checking is done on a image copy of the built
software, not on the originals.  (To prevent potential infection from the
tools, even though they are also kept only for this purpose.)
6) All originals have at least one copy kept off-site, at least one copy
kept on site in a locked vault, and additional copies (the ones actually
used) are kept in a locked room, only accessable to members of the SCM
group.
7) The copies sent to manufacturing for duplication are never inserted
into a machine for use; they are only used in an image copy duplication
machine.

There are other measures as well.  To sum it up, Apple Computer is
VERY aware of the potential problems of virus infections.  I find it
EXTREMELY difficult to believe that Apple has shipped any infected
software.  Whoever responded to your original request had a plausible
explanation; an infected dealer may use diskettes from a machine, put
them back, and pass the infection.  Naturally, Apple has no control
over such circumstances.  Only dealer education and safe software
practices can help.

As you say in your message, "...trust Apple.  Their business depends
upon it."

- --Brian Bechtel    [e-mail]
I can not officially comment for Apple, just as you can not offically
comment for your organization

------------------------------

Date: Tue, 21 Mar 89 11:16:05 mst
From: Hugh Gibbons <[e-mail]>
Subject: Viruses and the Media

Nicholas Geovanis is correct to point out that the unprofessional
treatment of viruses by the media is a part of a larger problem.  His
comments about US News & World Report are well deserved.  As American
news magazines go, however, US News is one of the better ones (usually
less sensational than Time or Newsweek, for instance).  What surprises
me is that reporters for the newspapers and magazines are not better
informed about viruses than they are, considering the fact that many
if not most of these reporters use computers on a daily basis; they
are as vulnerable to viruses as anyone.

But I guess if you live in the world every day and don't bother to
inform yourself about what's going on before reporting it, you
probably wouldn't bother yourself about data integrity either.

Hugh Gibbons         < [e-mail] >
University of Colorado
(the Wild West)

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest             Thursday, 23 Mar 1989        Volume 2 : Issue 70

Today's Topics:
Virus protection [and user removal] (Mac)
Report Query...
anti-virus recommendations from Computer World

---------------------------------------------------------------------------

Date: Wed, 22 Mar 89 10:41 MST
From: "Richard Johnson" <[e-mail]>
Subject: Virus protection [and user removal] (Mac)

MOSES@URVAX (quite a name, but aren't you mixing history?) writes:

> It has been brought to my attention that the users either Turn Off the
> protection or remove the vaccine so they may be able to use their
> infected applications.

At least one research center and three departments in the engineering
school here at the Univ. of Colorado have had their Macs infected
multiple times by nVIR.  At some sites, the people in charge don't
want to install _Vaccine because they do software development work.
There are alternatives, however.

The best general anti-viral utility I know of is an INIT/cdev called
GateKeeper.  Chris Johnson, its author, bills it as the "configure and
forget" approach to software protection.  It can block the
creation/modification of executable code and executable files by all
applications/INITs/etc. except those given special permission.
(Latest version is 1.1 - as of 3/20/89)

On the more specific anti-nVIR front, the RWatcher INIT is fantastic.
If it detects an application trying to add nVIR resources to another
file, it beeps 10 times and exits to the Finder.

Both of those ounces of prevention are in use at the center I work
for.  (Both are also free.)  It may just be coincidence, but we've
never had a machine infected.

There has been some user "resistance".  One of our more hot-headed
co-workers here was ranting yesterday about how GateKeeper was getting
in the way, throwing up stupid dialogs, and not letting him do his
work.  He'd ended up throwing it away and re-booting.  Turns out he
was just unwilling to take 15 seconds and give Tops and FORTRAN the
code modification and creation privileges they needed to work
correctly.  When I explained to him that once GateKeeper was
configured you didn't even need to think about it, he calmed down
somewhat.  But even with that illustration of how users will remove
anti-viral protection, we were still protected partially by RWatcher.

The main lesson I draw from this is that if a protection scheme is
*perceived* as getting in the way, some folks will remove it.
However, if it's unobtrusive, most users won't even know it's there
until they try an infected application.  We use a simple sign
directing users to see an advisor about their infected program if
their machine beeps 10 times or if GateKeeper vetoes a modification.
That way they're more likely to see someone who can help them rather
than removing the protection themselves.

Richard Johnson  <[e-mail]>

------------------------------

Date:     Wed, 22 Mar 89 13:54 EST
From:     John McMahon - NASA GSFC ADFTO - <[e-mail]>
Subject:  Report Query...

Was  a report  generated  on  the  "IBM Christmas  Card"  trojan horse
program that got loose in BITNET some time back ?  If  so, can someone
direct me to the server (or human being) that has it.

Thanks,
+------------------------------------+---------------------------------------+
|John "Fast Eddie" McMahon           |    Span: SDCDCL::FASTEDDY (Node 6.9)  |
|Advanced Data Flow Technology Office|    Arpa: [e-mail]|
|Code 630.4 - Building 28/W255       |  Bitnet: FASTEDDY@DFTBIT              |
|NASA Goddard Space Flight Center    |GSFCmail: JMCMAHON                     |
|Greenbelt, Maryland 20771           |   Phone: x6-2045                      |
+------------------------------------+---------------------------------------+

------------------------------

Date: Wed, 22 Mar 89 14:46 EST
From: Roman Olynyk - Information Services <[e-mail]>
Subject: anti-virus recommendations from Computer World

Several months ago, I asked if anyone had heard about a set of
recommendations for combating viruses that had appeared in Computer
World.  I had hoped that the article would provide me with a better
lead on the entire guidelines.  I've still not had any luck with the
later, but I did manage to find a shortened list (there were supposed
to have been twenty items in all) in the September 19 issue of
Computer World.  Here they are:

*   All software should be purchased from known, reputable sources.

*   All purchased software should be in its original shrink-wrap or
    sealed-disk containers when received.

*   Backup copies of all original software should be made as soon as the
    package is opened and stored off-site.

*   Before installation, all software should be reviews carefully by a
    systems manager.

*   New software should be quarantined on an isolated computer to
    greatly reduce contamination risk.

*   A backup copy of all system software and data should be made a least
    once a month and stored for at least one year before reuse.  This
    will allow restoration of a system that has been contaminated by a
    time-release virus.  A plan that includes "grandfathered" rotation
    of backup copies will reduce risk even further.

*   System administrators should restrict access to programs and data on
    a need-to-use basis.  This isolates problems, protects critical
    applications and facilitates problem diagnostics.

*   All programs on a system should be checked regularly for size
    changes.  Any size deviations could be evidence of tampering or
    virus infiltration.

*   Many shareware and freeware programs provide a prime entry point for
    viruses.  Skeptical review and extended quarantine of such programs
    are prudent.

*   Plans should be made to quickly remove any software that exhibits
    symptoms of contamination and to immediately back up all related
    data.  Users should be informed of these plans, which should be
    tested and reviews periodically.

These recommendation were made by a small working group of network
manufacturers.  I've seen some flames (justified, I believe) about the
second-to-the-last point dealing with shareware and freeware.
Shareware developers saw this as an industry ploy to discredit
non-commercial software developers.  Naturally, I'm still looking for
the entire set of guidelines, so I'd appreciate hearing from anyone
who can help me find them.

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest              Friday, 24 Mar 1989         Volume 2 : Issue 71

Today's Topics:
April 1st - Israeli virus strains
Request by Roman Olynyk--Manufacturer's Guidelines
TV Viruses
Russian Virus? (MS DOS)
Alameda Virus = Yale Virus

---------------------------------------------------------------------------

From:       David.J.Ferbrache <[e-mail]>
Date:       Thu, 23 Mar 89 13:13:37 GMT
Subject:    April 1st - Israeli virus strains

Hello, just a quick note regarding April 1st IBM viruses,

As I suspect many of you will be aware there are two variants of the
Friday 13th Israeli virus which have as their target date April 1st,
these are:

sURIV 1.01 which infects only .COM files
sURIV 2.01 which infects only .EXE files

They display the message "APRIL 1st HA HA you have a virus" on this
date on execution of an infected .COM file or .EXE file. The virus
causes a lockup immediately in the case of the .EXE variant or after
execution of a further .COM file in the case of the .COM variant.

The .EXE variant also has a lockup 1 hour after execution of an
infected .EXE file when the default date (1-1-80) remains unchanged.

This is based on Y.Radai's report on the Israeli viruses appearing in
VIRUS-L on 2 May 1988, hopefully he will provide further details.

The above variants seem less well known than the MsDos (1808/1813)
Friday 13th virus, however judging by their infection characteristics
I see no reason why they should not spread rapidly if released, unlike
the sURIV 3.00 variant of Friday 13th whose 30 second delay prior to
the insertion of the timer tick delay loop would make it easily
identifiable and considerably less dangerous.

I would be interested in any reports of these two strains, especially
those in the UK and/or continental Europe.

Dave Ferbrache                            Personal mail to:
Dept of computer science                  Internet <[e-mail]>
Heriot-Watt University                    Janet    <[e-mail]>
79 Grassmarket                            UUCP     ..!mcvax!hwcs!davidf
Edinburgh,UK. EH1 2HJ                     Tel      (UK) 031-225-6465 ext 553

------------------------------

Date: Thu, 23 Mar 89 12:29:10 MST
From: Chris McDonald  ASQNC-TWS-R 678-4176 <[e-mail]>
Subject: Request by Roman Olynyk--Manufacturer's Guidelines

I have subscribed to Computer World for several years, and I do not
specifically every seeing the specific guidelines which Roman
mentioned.  I do have a copy of something which is very close which
appeared in the Computers and Security Journal, April 1988.  That
edition, which is devoted exclusively to computer viruses, has a list
of 14 "suggestions" to commercial companies in advising them how to
reduce the viral risks.  A footnote adds that in later issues of the
journal additional measures would be listed.  The same edition also
provides a product evaluation of 18 virus protection products.

The entire edition is still one of the best primers in my opinion on
viruses Articles by Fred Cohen, William Murray, Joseph Highland are
particularly good.

Might it be the source, rather than Computer World?

Chris McDonald
White Sands Missile Range

------------------------------

Date:     THU MAR 23, 1989 15.55.31 EST
From:     "David A. Bader" <[e-mail]>
Subject:  TV Viruses

I just saw the latest episode of Star Trek: The Next Generation
episode: Contagion.  The Enterprise encounters a device that transmits
alien code into their own.  Systems in the ship start to break down,
and anything that reads this code gets infected (e.g. Data, Romulan
ship, etc.)  Anyway, because this code is foreign to the softwar being
run, these ill effects occur and no one knows what to do. Their
solution (as Data purges his systems): clear ALL memory and re-load
all data from uninfected archives.

Is this one way to educate the public on viruses?

------------------------------

Date:         Thu, 23 Mar 89 19:13:39 CST
From:         "Mark S. Zinzow" <[e-mail]>
Subject:      Russian Virus? (MS DOS)

A Virus was discovered today in a research lab here at the University
of Illinois at Urbana-Champaign.  I've never heard of this one before,
so I'm hoping maybe someone who has could fill me in.  It infects
COMMAND.COM without changing its size.  It can be recognized by
looking for the following string in that file:

$You have just activated a Russian Virus...THANK You! .........^M^J$

The virus likes to go off during a disk I/O operation and will do
something like complain about a write protect error on a hard disk and
display the above message after every subsequent keypress.  It may
just be a simple hack to command.com as a prank; I have not had time
to play with it to learn more.

- -------Electronic Mail----------------------------U.S.
 Mail--------------------
ARPA: [e-mail]         Mark S. Zinzow, Research Programmer
BITNET: [e-mail]         University of Illinois at Urbana-Champaign
CSNET: [e-mail]      Computing Services Office
 "Oh drat these computers, they are  150 Digital Computer Laboratory
   so naughty and complex I could    1304 West Springfield Ave.
  just pinch them!"  Marvin Martian  Urbana, IL 61801-2987
USENET/uucp: {uunet,convex,att}!uiucuxc!uiucuxe!zinzow
Phone: [phone]  Office: CSOB 110 \033markz%uiucvmd

------------------------------

Date: Thu, 23-Mar-89 19:32:13 PST
From: portal!cup.portal.com![e-mail]
Subject: Alameda Virus = Yale Virus

In VIRUS-L 2.62, David M. Chess asked about the "Alameda Virus" -
> John McAfee's article in the Feb 15 issue of Datamation, "The Virus
> Cure" (good article, poor title) lists a boot-sector virus that he
> calls the "Alameda Virus".  I've never heard that name before, and it
> isn't on Dave Ferbrache's February list.  It does sound sort of like
> the "Yale" boot virus (which McAfee doesn't list under that name);
> does anyone know if the two are in fact the same?

I relayed David's question to John McAfee, and here is John's response:

! 03/14/89 22:34:46
! From: JOHN MCAFEE
!
! The Alameda and Yale virus are in fact the same.  It was first
! discovered at Merritt College, Oakland, in April of 1977, but garnered
! little publicity at the time.  A major outbreak occurred at Alameda
! College (Alameda, CA) in February of 1988 which was widely publicised
! on the West Coast - hence its name.  By all rights, however, it should
! be called the Merritt virus.
!
! Thanks for the comments on the article.  I had nothing to do with the
! title.  It was submitted to Datamation with the title - 'A cursory
! overview of the more obvious issues of virus replication - with a
! brief description of generic methods of virus protection, and
! including an outline of the more common viruses.  By John McAfee'.  I
! guess Datamation didn't care for it.

- ----------------------------
Gary F. Tom
Tandem Computers Inc.             Internet: <[e-mail]>
19333 Vallco Parkway Loc 3-22         UUCP: sun!portal!cup.portal.com!garyt
Cupertino, CA 95014                  Phone: [phone]

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest              Monday, 27 Mar 1989         Volume 2 : Issue 72

Today's Topics:
Re: Dick Tracy vs. viruses
Viruses & Media Inaccuracy
Request for IBM PC Anti-virals

---------------------------------------------------------------------------

Date:         Fri, 24 Mar 89 12:17:00 EST
From:         Ed Nilges <[e-mail]>
Subject:      Re: Dick Tracy vs. viruses

I noticed that Dick Tracy is getting into computer viruses.  The
strip, which has run for years (and which was pulled by several papers
years ago because of its violence and sleazy characters), is currently
dealing with Tracy's fight against some bum who has infected the
police department's machines.  The strip seems to ignore the fact that
mainframe computers have numerous offline and human controls that
would make such an event extremely unlikely.  As such, it is spreading
disinformation.

------------------------------

Date:    Thu, 23 Mar 89 11:49 EST
From:    "J. D. Abolins" <[e-mail]>
Subject: Viruses & Media Inaccuracy

  Relative lack of familiarity with computers is not the only reason
  for innacuray in media virus reporting. Among other factors, there
  is the notion that the readers/viewers would not understand the
  details or would have little interst if the complexities were
  proper;y explained. It is not only the media that takes this view.
  I have talked with computer security professionals who believe that
  it is better to blur the destinction between the classic viruses and
  other problem programs than to risk confusing the public.

  Another factor is the problem of type/time fitting. If a reporter
  has only 1000 words or three minutes of air time to report a virus
  case, it encourages the reporter to cut out details and paint
  everything with a large brushstroke. (I have gone through this
  fitting problem recently when I was asked to write a virus article
  for a NJ State Govt. MIS newsletter. If it's hard for someone who
  is aware of the complexities, how much harder it is for someone who is
  baffled by the complexities.)

------------------------------

Date:         Fri, 24 Mar 89 13:19:43 EST
From:         Arthur Gutowski <[e-mail]>
Subject:      Request for IBM PC Anti-virals

I'm fairly new to this list, and I have seen this question crop up
in past digests, but I'll go ahead and ask it again anyway...

Here at Wayne State, our Computing Center has recently become actively
involved in fighting viri on a large scale.  We formed a small group
on campus primarily responsible for disinfecting campus machines (both
Macs and IBMs), making available PD and Shareware anti-virals to the
university public, and educating people in preventative medicine.

We are just getting off the ground, so I was hoping someone could help
me out with this. I am looking for *any* IBM PC anti-virals in
addition to what's on the Virus-l filelist at Lehigh.  I have already
gathered what's out there (at Lehigh) as a start, and I have also
looked at the SCFVM's PUBLIC list (most of what's there seems to be
Macintosh vaccines).

I have heard mention of some other disinfectors/prevention mechanisms
in addition to what's on virus-l (including HDSENTRY, DEBRAIN, and
Vaccine.com) and some newer releases (FSP 1.51 and CHECKUP 2.1).  Any
other reliable disinfectors/checkers/etc. (PD, Shareware, or
commercial) are welcome and appreciated.

I would be very appreciative if you could give me any sources to look
into, where can I get some programs, or if you have copies of any
programs if it is possible to send them to me via my Bitnet address.

Please send responses, etc. directly to me.

Thanks in advance...

   Art

PS>  Thanks for your help and advice, Ken.

- -=[e-mail]  ~This TIME-SpacE ConTINuuM is FluuctuatING AGAin~=-

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest             Tuesday, 28 Mar 1989         Volume 2 : Issue 73

Today's Topics:
KillVirus Init (Mac)
Transposing Virus (PC)
Re: anti-virus recommendations
UK Computer threat research association

---------------------------------------------------------------------------

Date: Sun, 26 Mar 89 00:38:49 +0100
From: David Stodolsky <[e-mail]>
Subject: KillVirus Init (Mac)

KillVirus Init for Mac
"KillVirus", a startup document for the Mac, was found to be
infected with "nVIR" by Interferon 3.1. The infection was
confirmed by Virus Rx. The information box indicated its size
to be "979 bytes used, 1K on disk". The creations date was
"Tue, Sep 10, 1985, 10:08 AM", Modified "Tue, Mar 22, 1988,
9:14 AM". Version indicated "not available". The icon was a
generic document.

The document was never used, just placed in my "Anti-virus"
folder. I have deleted the document from my hard disk and
taken no further action. I ran the checks after an attempt to
start a shareware program "Concentration", which I thought
was a game, caused a screen disruption, a buzz from speaker,
and a system restart (Mac SE, System 6.0.2, Multi-finder
6.0.1. I had Vaccine version 1.0, without expert mode on.)
When I tried to copy "Concentration" to a folder on
the hard disk, I got an error, but my copy of the original (a
whole disk copy) to another floppy disk had worked. An
attempt to recopy the original back to the same floppy after
deleting the game (and emptying the trash) gave a error
indicating a failure on the target disk! Checking this disk
with "Disk First Aid" found it to be OK. This made me think
that a virus check of the disk was in order, but no virus was
found on it. Later I tried another whole disk copy to the same
target disk that failed with an "unknown error" message.
After reinitializing the target disk a whole disk copy worked,
and it was possible to move the Concentration application to
a folder on the hard disk. An attempt to execute it again led to
the system hanging, and I had to do a restart manually ( by
pressing the programmer's key). I had rebuilt the desktop after
the initial crash, so that might explain the different behavior.
Or maybe it was because the Concentration application was run
before any other application the last time I tried it.

Is this really an infection, or is "KillVirus" an init that
happens to trigger both of these anti-virus programs?

****************** Interferon Report *****************

Interferon 3.1 - Version of 16 May 88 - 1988 Robert
Woodhead, Inc. - All Rights Reserved

- ------------ lines deleted----------------

(002) 04/07/88 "nVIR" Virus

- --------------lines deleted-------------------

Checking for viral infections on volume "HD0"

INFECTION: Type 002 virus detected in file:
HD0:
applications:
Anti-viral:
KillVirus

ALERT! Volume "HD0" may be infected!
Consult listing to determine the details.

Interferon run completed!
2197 files were scanned, of which 207 had resource forks.

******************** Virus Rx report **********************

Volume:    HD0
Thursday, March 23, 1989   8:30 PM
User:
Virus Rx - v1.4a1

These files are infected with a known virus
Remove these files from your disk

INIT ????  KillVirus  :applications:Anti-viral:
  Last modified Tuesday, March 22, 1988 9:14 AM


SUMMARY:
***** FATAL infected files: 1

!!!!! You appear to have a virus !!!!
!!!!! Clean this volume          !!!!
!!!!! See Virus Rx README        !!!!

******************************************************

David Stodolsky                          diku.dk![e-mail]
Department of Psychology                       Voice + 45 1 58 48 86
Copenhagen Univ., Njalsg. 88                    Fax. + 45 1 54 32 11
DK-2300 Copenhagen S, Denmark                         [e-mail]

------------------------------

Date:         Sun, 26 Mar 1989 00:52:18 EST
From:         Steve <[e-mail]>
Subject:      Transposing Virus (PC)

Ross M. Greenberg wrote about a virus that randomly tranposed
characters but kept track of all the transpositions in a hidden file
called BUG.DAT:

>                                .
>                                .
>                                .
>The virus, after spreading to all .COM and .EXE files in the current
>directory, would look for an open operation on a .DBF file.  All
>writes to the file would have two bytes transposed at random. These
>bytes' offsets were stored in a file called "BUG.DAT" (a hidden file)
>in the .DBF's directory.  Subsequent reads of this data would cause
>the transposition of the same data, and everything would look nifty.
>After this code had run for 90 days (after the BUG.DAT file was 90
>days old), it would trash the disk (eat the FAT and root directory).
>
>Getting rid of the virus wasn't difficult: just copy in new
>executables from your backup.  However! If you did this, your data is
>history - nothing to transpose it back into "real" form.

Just some comments:

   So the virus must keep all the .DBF file names and all their
transposed characters in the file called BUG.DAT?  It seems to me that
if you made the mistake of getting rid of the infected *.EXE file it
wouldn't be a disaster because you'd probably still have the hidden
file BUG.DAT somewhere and could always recreate the infected file
(provided you had or could import another file infected with the
virus).

   All this brings up a good point: If one day I found that my
computer was infected with a virus, *before doing anything*, I'd first
make a backup of all the files on my disk (hidden files too!).  Then
I'd try to verify that all my data files (anything that wasn't an .exe
or .com file) on the backup were identical to the originals on the
main disk and hopefully intact.  Then I'd go to work trying to
eliminate the infection.  If something went wrong, then I'd still have
my backup.  This is reasonably safe unless one encounters a virus like
the one Ross describes, only which hides the transposed-character
information in a file in a sector marked bad (even though it isn't
bad), and then (for example) you reformat the original disk (a
disaster because you'd lose BUG.DAT).  So, though it's more trouble,
it's always safer to "uninfect" a copy of your infected disk if
possible.

   Finally, if you're really unlucky and the virus contains a bomb, it
could blow still blow up before you get all your files "un-transposed"



Steven C. Woronick     | Disclaimer:  Always check it out for yourself...
Physics Dept.          |
SUNY at                |
Stony Brook, NY  11794 |
Acknowledge-To: <XRAYSROK@SBCCVM>

------------------------------

Date:         Mon, 27 Mar 89 14:17:59 EST
From:         Neil Goldman <[e-mail]>
Subject:      Re: anti-virus recommendations

Roman Olynyk provides us with the anti-virus recommendations from
Computer World.  There is one with which I disagree (to an extent).

In regard to shareware and PD software, I do believe that users should
be cautioned that they are the primary (though not exclusive) source
of viruses do to their widespread availability.  As you are all aware,
users will obtain a copy from a friend, business associate, or even a
bulletin board.  Since in the first two, and periodically in the
third, no controls exist to prevent the corruption of the product from
its original form (which for the sake of argument I assume did not
have any malicious intent).

However, I do not believe that an end to PD and shareware is called
for.  In the vast majority of cases, they are excellent products,
often rivaling their industry-marketed counterparts.

As an alternative to the Computer World suggestion, I recommend that
IF users want to take advantage of this software, they should contact
the ORIGINAL AUTHOR for a copy.  Presumably, his product is
*uncorrupted*.  Then, if a virus does then become introduced into your
system and you have documented the source of all data and programs
existing on your system, the source of the virus is determinable.  Or
rather, no virus *should* infect the system to begin with.

***************************************************************
*Neil A. Goldman                        [e-mail]*
*                                                             *
*   Replies, Concerns, Disagreements, and Flames expected     *
*    Mastercard, Visa, and American Express not accepted      *
***************************************************************
Acknowledge-To: <NG44SPEL@MIAMIU>

------------------------------

Date:       Tue, 28 Mar 89 10:33:16 BST
From:       David.J.Ferbrache <[e-mail]>
Subject:    UK Computer threat research association

For those of you interested an umbrella organisation has been
established in the UK to co-ordinate information on, and research into
all aspects of computer security. In the first instance one of the
organisations primary concerns will be combatting the threat posed by
computer viruses by acting as a clearing house for virus information
and control software.

Below is a copy of an initial letter mailed to prospective members:

            The Computer Threat Research Association

The computer threat research association, CoTra is a non-profit making
organisation that exists to research, analyse, publicise and find
solutions for threats to the integrity and reliability of computer
systems.

The issue that caused the formation of CoTra was the rise of the
computer virus. This problem has since become surrounded by fear,
uncertainty and doubt. To the average user the computer virus and its
implications are a worry of an unknown scale. To a few unfortunates
whose systems have become a critical issue.

The key advantage of CoTra membership will be access to advice and
information.  Advice will be provided through publications, an
electronic conference (a closed conference for CoTra's members has
been created on the Compulink CIX system) as well as other channels
such as general postings direct to members when a new virus is
discovered.

CoTra membership will be available on a student, full or corporate
member basis. All software that is held by CoTra that enhances system
reliability, such as virus detection and removal software, will be
available to all members. It is intended to establish discounts with
suppliers of reliability tools and services. A library of virus
sources and executables and other dangerous research material will be
made available to members who have a demonstrable need.

A register of consultants who have specific skills in the systems
reliability field will be published by CoTra and reviews of
reliability enhancing software will be produced.

Your support of CoTra will ensure that you have the earliest and most
accurate information about potential threats to your computer systems.

CoTra, The computer threat research association,
c/o 144 Sheerstock, Haddenham, Bucks. HP17 8EX

- ----------------------------------------------------------------------------

Part of the organisations aims is to establish reciprocal links with
other similar organisations worldwide to facilitate the sharing of
experience and rapid flow of information on new threats.

To this end if you are involved in, or have contacts with, a similar
organisation in your country, please write to CoTra (or by email to
me, and I will forward your correspondence) outlining your
organisation and its aims.

Yours sincerely

- -------------------------------------------------------------------------
Dave Ferbrache                         Personal mail to:
Dept of computer science               Internet <[e-mail]>
Heriot-Watt University                 Janet    <[e-mail]>
79 Grassmarket                         UUCP     ..!mcvax!hwcs!davidf
Edinburgh,UK. EH1 2HJ                  Tel      (UK) 031-225-6465 ext 553

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest             Tuesday, 28 Mar 1989         Volume 2 : Issue 74

Today's Topics:
RE: virus in PD software
Disinfect 1.0 (Mac)
The KillVirus Alarm (Mac)
(from UseNet rec.ham-radio) virus in PKZIP? (PC)
Re: Israeli viruses; Alameda virus (PC)
RE:  Zip virus (PC)

---------------------------------------------------------------------------

Date: Tue, 28 Mar 89 09:41 EST
From: Roman Olynyk - Information Services <[e-mail]>
Subject: RE: virus in PD software

Neil Goldman's comments about virus lurking in PD/Shareware are good.
However, I'd like to add yet another way of obtaining "sanitized"
copies of public domain good: CD-ROM.  We (WVNET) distribute software
from PC-SIG directly off of a laser disk.  Although not 100%
guaranteed, you can be sure that nothing can corrupt the software once
it has been burned onto a CD-ROM disk -- at least not yet! ;-)

------------------------------

Date: Tue, 28 Mar 89 09:48:42 EST
From: [e-mail] (Kenneth R. van Wyk)
Subject: Disinfect 1.0 (Mac)

A colleague just showed me a program, called Disinfect (version 1.0)
that was announced in INFO-MAC.  It claims to do quite a bit,
including detect most major Mac viruses (Scores, ANTI, AIDS, Init 29,
MacMag, etc.), and it is even supposed to be able to remove most
(all?) of the above.  The claims are quite impressive.  I'm not a Mac
user, however, so don't take my word for it.

Anyone Mac people out there have any more info on this?

Ken

------------------------------

Date:    Tue, 28 Mar 89 11:41 EST
From:     <[e-mail]>
Subject: The KillVirus Alarm (Mac)

(This is in response to the recent report of an infection to the
program resource KillVirus, for the Macintosh....)

If memory serves me correctly (and I am sure that I will be corrected
if I am wrong) KillVirus is not a program per se.  The resource is
meant to be the culture where viruses can infect a 'resource' and then
the program can be edited to determine the exact workings of the
virus.  If you are waging war against a new virus this can be an
extremely good thing, as you do not have to root around in the source
code to find what you are looking for.

If this is true (as I said before) then remove this copy of KillVirus
and replace it with a clean copy.  But be forewarned : you most
certainly have a system infection on your hands, so before you go
using your system, I reccomend a dose of Interferon (to find
infections) and Vaccination (to remove them).  Also - replace the
system.  This is the safest way of making sure you have a clean one to
work with.

I am open for comments or questions....after all, trying to keep our
labs free of contamination keeps me open for help....

Thanks

Jonathan Baker                 JEB107 @ PSUVM
                                        Penn State University.

------------------------------

Date:         Tue, 28 Mar 89 11:49:25 EST
Sender:       Virus Alert List <[e-mail]>
From:         [e-mail]
Subject:      (from UseNet rec.ham-radio) virus in PKZIP? (PC)

Original-Date: 25 Mar 89 03:56:53 UTC (Sat)
Original-From: [e-mail] (BOB        )

         PKZIP/PKUNZIP .92
         AM40/AM41

Recent developments in the software world have required the famous
PKARC software to be replaced by a new version called PKZIP/PKUNZIP.

While several versions have been seen, the latest appears to be
version .92 .  Usually listed on landline BBS's is a program which
will provide a menu driven screen for PKZIP, usually listed as AM-40
or AM-41.

After running these one time, the embedded virus allocated 13 meg of
memory to "never never land". It appears that this "strain" looks to
see how much memory is occupied on the HD and then proceeds to gobble
up an equal amount of unused memory.  The results are devastating if
you have more than 50% of the drives capacity in use.  With the
assistance of Gary WA2BAU I was able to retrieve the lost memory by
using CHKDSK /f.  For those of you who are not familiar with this DOS
command, drop me a line @KD6TH and I'll elaborate.  My sincere thanks
goes out to Gary WA2BAU for saving me lots of disk handling !  Please
pass this on to your local BBS and be sure to include the remedy.

    Best 73 de WA2SQQ
    Bob Kozlarek
    @KD6TH in Wycoff,
    NJ

[Ed. Can anyone verify that this is actually a virus and not just a
bug in the program, or a Trojan Horse?]

------------------------------

Date:        Tue,  28 Mar 89 18:30:58 +0200
From:        Y. Radai <[e-mail]>
Subject:     Re: Israeli viruses; Alameda virus (PC)

  To begin with, I thought it appropriate to warn readers that Fri13
(the Israeli Friday-the-13th virus) has apparently been "improved"
(i.e. made less noticeable) by someone in the U.S. so that it
increases the size of EXE files only once, does not cause a slowdown
after 30 minutes, and does not scroll the screen.  Of course, it still
causes deletion of files executed on any Friday the 13th.

  In #71, David Ferbrache mentioned the two April 1 viruses which were
discovered in Israel [at the beginning of 1988].  I too would like to
hear of reports of the April 1 viruses elsewhere, not only recent
outbreaks but also at any time in the past so that we can know whether
these viruses really originated in Israel.
  Dave asked me for further details on these viruses.  In principle,
I'd be glad to oblige, but that requires research, which requires
time, and since neither of these viruses seems to cause any real
damage and both have apparently been eradicated locally, such research
necessarily gets low priority.  However, I will take this opportunity
to make a few small clarifications and corrections to Dave's descrip-
tion: (1) The variant of Fri13 ("sURIV 3.00") is not only "less
dangerous", but not dangerous at all due to a bug; (2) the names
"sURIV x.xx" which Dave has given them are based on strings which
appear in the viral code (but they could probably be altered without
disabling the viruses); (3) I wouldn't describe the April 1 viruses as
"variants of the Friday 13th virus".
  In any case, I've promised to supply Dave with anti-viral programs
and various text files for his server (sorry for not doing it yet,
Dave), and will do so as soon as I find the time.  At that time I'll
also post a notice to the List.

  In #62 David Chess mentioned the Alameda Virus which was described
by John McAfee in the Feb 15 issue of Datamation.  Now I had seen
another article of McAfee's in the Feb 13 issue of Computerworld which
contained the same table of "the 6 most common computer viruses", and
like David, I also conjectured that Alameda = Yale.  Actually, from
the few details which McAfee gives, about the only similarities are
that both are PC boot sector viruses which do *not* mark as bad the
sector on which they store the original boot code.  However, the fact
that none of the values of the generation counter found at Yale last
August were less than 12h  could be explained if Yale were a continu-
ation of some other virus, such as Alameda.
  However, there was one point which bothered me:  McAfee describes
the Alameda virus as follows: "Stores original boot sector on first
free sector."  Now this is *not* true of the Yale virus, which always
stores it in the ninth sector of Track 40.  I decided that the des-
cription by Chris Bracy and Loren Keim of the Yale virus was far more
dependable than McAfee's meager description of the Alameda, and that
there was a good chance that the two viruses are the same, after all.
  But what I don't understand now is what basis *McAfee* has for
stating categorically that the two viruses are the same.
  And there's another peculiarity:  In his original article, McAfee
wrote that the origin of the virus was "Merritt College ... spring
1988".  However, in his response of Mar 14 which was reprinted in
VIRUS-L #71, he says "It was first discovered at Merritt ... in April
of 1977".  I originally thought: well, he obviously means April of
1988.  But later he writes that the virus reached Alameda in Feb 1988.
So now I'm thoroughly confused!
  So Gary, since you obviously are able to contact McAfee, would you
mind asking him (1) to clarify the inconsistency in the dates, (2) to
give us all available details on the Alameda-Merritt virus, and (3) to
provide all the evidence he has for concluding that Alameda = Yale.

                                           Y. Radai
                                           Hebrew Univ. of Jerusalem

------------------------------

Date:     Tue, 28 Mar 89 14:48 EDT
From:     Paul Coen <[e-mail]>
Subject:  RE:  Zip virus (PC)

>While  several versions have been seen, the latest appears to be
>version .92 .  Usually listed on landline BBS's is a program which will
>provide a menu driven screen for PKZIP, usually listed  as AM-40 or
>AM-41.
>
>After running these one time, the embedded virus allocated 13 meg of
>memory to "never never land". It appears that  this "strain" looks to
>see  how much memory is occupied on the HD  and then proceeds  to

Is the virus in PKZIP or in AM-40?  From the sound of it this is in
AM-40.  Also, I've been running PKZIP 0.92 for a couple of weeks (on
my HD) without a problem.  I would adivse anyone looking to get Zip to
either get it from someone reliable, or, from the PKWARE BBS in
Wisconson.  Also, any front-end menu programs should be downloaded
from there.  I don't have the number handy, but if anyone wants it I
can get it.  I'm not very suprised at this, since ARC/ZIP type
programs have been a favorite of program writers for a couple of years
now.  Thanks for the warning.....

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest            Wednesday, 29 Mar 1989        Volume 2 : Issue 75

Today's Topics:
"dBase virus" (PC)
disinfectant (Mac)
RE: Virus in PD Software
Television & viruses
News Usenet group comp.virus
Re: Israeli viruses (PC)
Disinfectant (Mac)

---------------------------------------------------------------------------

Date: Tue Mar 28 22:23:43 1989
From: utoday![e-mail]
Subject: "dBase virus" (PC)

Hmmm.  Although the transposition algorithm in the (what I'm calling)
the dBase Virus was pretty simple, it took a while to hack through the
virused code to see what was happening.  Far easier than
reconstructing the algorithm was merely to defang it as I indicated in
my posting.

Consider if the bad-guy encrypted the transposition-information file.

Besides, I took some sort of perverse joy out of using the bad guys's
code to reverse his "work"  (we must all get our pleasures in some
strange way, right? :-) )

Ross M. Greenberg
UNIX TODAY!             594 Third Avenue   New York   New York  10016
Review Editor           Voice:(212)-889-6431  BBS:(212)-889-6438
uunet!utoday!greenber   BIX: greenber  MCI: greenber   CIS: 72461,3212

------------------------------

Date:         Wed, 29 Mar 89 08:03:27 CET
From:         "Willem N. Ellis" <[e-mail]>
Subject:      disinfectant (Mac)

Disinfectant was announced a few days ago on the Infomac list. Bitnet
users may obtain it from the LISTSERV @ RICE by sending a mail with as
only text: $macarch get virus/disinfectant.hqx

Unfortunately, I do not have description of the program at hand, but
it looked impressive indeed.

Willem N. Ellis

------------------------------

Date:     Wed, 29 Mar 89 00:05 EST
From:     "SYSOP, THE SHENANDOAH VALLEY HELPLINE BBS: [phone]"
          <STU_CWHITES@JMUVAX1>
Subject:  RE: Virus in PD Software

Roman Olynyk writes that CD-ROM is a good source of "sanitized"
software.  Although it may be more reliable than software downloaded
from a local BBS, it still doesn't assure you of a clean program.
Recently, here at JMU, several versions of Macintosh viruses made it
onto campus through just such a media.  Although the CD-ROM is
unaffected by the virus, the software on it can be replaced.  Not so
for the data residing on your PC that you've put so much work into.  I
am a strong believer in the PD/Shareware concept, and feel that the
programs are as safe as the shrink wrapped variety.  However, I also
think that getting it from the source is a reasonable precation.

                                Chip Whiteside

------------------------------

Date:     Tue, 28 Mar 89 21:35 EST
From:     <[e-mail]>
Subject:  Television & viruses

FYI -- television & viruses

I'm not sure how many "trekkies/trekkers" subscribe to this list, but
this is the latest medium for public awareness of viruses.  Last weeks
Star Trek -- the Next Generation was centered around (of all things)
viruses.  The Enterprise was heading to the neutral zone to meet with
a ship who was investigating a strange planet.  During the ships
contact with the planet, it received transmissions that were stored in
the computer banks.  After that, the ship began to experience mishaps
and system failures here and there.  When the Enterprise finally met
up with the ship, they barely had time to download the logs and data
before the ship exploded.  They were convinced that it was a design
flaw with the ship and not due to any external force.

Well, to make a long story even longer, the Enterprise began to
experience the same problems. Through careful analysis, they
discovered that the errors were caused by a program which was attached
to the downloaded logs. The program, once in the Enterprise's banks
began to adapt to the environment and seek out available space and
re-generate itself throughout the whole system.  After a good amount
of storyline, they finally figured out that the way to get rid of the
"virus" was to shut down systems and (I'm paraphrasing) re-format and
re-initialize from backups which were locked and stored in one of the
bays.

For a change, I saw nothing wrong with the way viruses were dealt with
in a television program.  This is far from the teenage revenge hacker
with black, thick-rimmed glasses seeking to destroy the government.

If anyone else has seen it, please let me know what you think.

Reply to: RER1@SCRANTON

------------------------------

Date: Wed, 29 Mar 89 07:53:15 CST
From: [e-mail]
Subject: News Usenet group comp.virus

To all virus-l readers,

As some of you may be aware, there is an effort underway to
establish a new newsgroup on the Usenet system: comp.virus.
This group will have close ties to virus-l.  The group will
be moderated by Ken van Wyk.  All traffic on virus-l will
appear on comp.virus, and vice-versa.  The most significant
benefit of this will be the much larger base of informed
computer users who can contribute to the group.  Usenet
propogates throughout the entire world, and has ties to
many different networks.

As a supplement to the creation of comp.virus, I have been
trying to coordinate the establishment of a number of
anti-viral archive sites.  We currently have commitments
for archive sites for Amiga, AppleII, Atari ST and Mac
computers.  I'm still trying to find an IBM PC site.

Dave Ferbrache will be the European coordinator of comp.virus.  He
will handle issues of particular interest to European readers
(conventions, archive sites, etc.).

New group creation procedures on Usenet require an initial
call for discussion, followed by a two week discussion
period.  Then a call for votes is posted, and a four week
voting period ensues.  After this, the group is created if
(1) at least 100 votes have been received and (2) if the
number of YES votes exceeds the No votes by at least 100.

We are currently in the voting stage, which will end April 23.
If you would like to cast a vote on this, send mail to

                [e-mail]

To vote for the creation of comp.virus, include the word
"YES" in the subject line or body of the message.  To vote
against the creation of comp.virus, include the word "NO".
Please, only vote if you actually receive Usenet and are
a potential reader of comp.virus.

Jim Wright
[e-mail]

------------------------------

Date:        29 March 1989, 09:42:55 EST
From:        David M. Chess <[e-mail]>
Subject:     Re: Israeli viruses (PC)

I have seen two "April 1st" viruses (they came to me from Israel; no
telling where they started, of course!).  One infects COM files and,
if I'm reading it right, will display the message "YOU HAVE A VIRUS"
any time any program is run in an infected system after April 1, 1988.
So this one isn't likely to be around any more, if it ever was
(because any infected system would be so obviously infected).

The other one infects EXE files.  It will print a message ("APRIL 1ST
HA HA HA YOU HAVE A VIRUS") and hang the machine on any April 1st in
1988 or after.  On any Wednesday after 1988/3/1, it will install a
timer hook which will hang the system later on.  If the year is 1980
(not set), it will also install the hook.  So infected systems will
hang on Wednesdays; again, a very unsubtle virus!

I haven't heard any reports of either one recently, or outside of
Israel.  Of course, there may be other similar viruses around, and my
notes above may not be at all true for them.  If you get a virus that
sounds like it might be one of them, have a guru rip it thoroughly
apart, to make sure...

DC

------------------------------

Date:        29 March 1989, 11:20:55 EST
From:        [e-mail]
Subject:     Disinfectant (Mac)

Yes, Disinfectant is for real.  I'm the author.  I'm attaching a copy
of the announcement I posted on the internet.

The program is available via anonymous FTP from:

   sumex-aim.stanford.edu
   rascal.ics.utexas.edu

It's also available on CompuServe, Genie, BIX, MacNet, CI$, Delphi, and
AppleLink.

- ---------- Announcement:

Disinfectant 1.0 is the first public release of a new program to
detect and remove Macintosh viruses.

Features:

- - Detects and repairs files infected by Scores, nVIR A, nVIR B, Hpat,
  AIDS, INIT 29, ANTI, and MacMag.  These are all of the currently known
  Macintosh viruses.
- - Scans volumes (entire disks) in either virus check mode or virus
  repair mode.
- - Option to scan a single folder or a single file.
- - Option to "automatically" scan a sequence of floppies.
- - Option to scan all mounted volumes.
- - Can scan both MFS and HFS volumes.
- - Dynamic display of the current folder name, file name, and a thermometer
  indicating the progress of a scan.
- - All scans can be canceled at any time.
- - Scans produce detailed reports in a scrolling field.  Reports can be
  saved as text files and printed with an editor or word processor.
- - Carefully designed human interface that closely follows Apple's
  guidelines.  All operations are initiated and controlled by 8 simple
  standard push buttons.
- - Uses an advanced detection and repair algorithm that can handle partial
  infections, multiple infections, and other anomalies.
- - Careful error checking.  E.g., properly detects and reports damaged and
  busy files, out of memory conditions, disk full conditions on attempts
  to save files, insufficient privileges on server volumes, and so on.
- - Works on any Mac with at least 512K of memory running System 3.2
  or later.
- - Can be used on single floppy drive Macs with no floppy shuffling.
- - 8500 word online document describing Disinfectant, viruses in general,
  the Mac viruses in particular, recommendations for "safe" computing,
  Vaccine, and other virus fighting tools.  The document can be saved as
  a text file and printed with an editor or word processor.  We tried to
  include everything in the document that the average Mac user needs to
  know about viruses.

I wrote Disinfectant with the help of an international group
of Mac virus experts, programmers and enthusiasts: Wade Blomgren,
Chris Borton, Bob Hablutzel, Tim Krauskopf, Joel Levin, Robert Lentz,
Bill Lipa, Albert Lunde, James Macak, Lance Nakata, Leonard Rosenthol,
Art Schumer, Dan Schwendener, Stephan Somogyi, David Spector, and
Werner Uhrig.

These people helped design and debug the program, edit the document,
locate copies of the viruses for testing, and analyze the viruses.  I
wrote all the code, but I could not have written the program without
their help.

Disinfectant is an example of a new kind of cooperative software
development over the internet. It was developed over a period of three
and one half months starting on December 1, 1988. During this period I
sent out nine development releases and nine Beta releases to the
working group, and we exchanged several hundred notes. The result is a
program that is much better than any one of us could have produced
individually.

We are offering this program free of charge as a public service.  We
hope that the Mac community finds it useful.

John Norstad
Academic Computing and Network Services
Northwestern University

Bitnet:      jln@nuacc
Internet:    [e-mail]
AppleLink:   a0173
CompuServe:  76666,573

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest             Thursday, 30 Mar 1989        Volume 2 : Issue 76

Today's Topics:
Disinfectant for Mac
RE: Star Trek virus
PKWare virus? (PC)
Not really an nVIR (Mac)
Disinfectant (Mac)
New England J. of Med. letter
KillVirus Init not malevolent (Mac)
Re: KillVirus Init (Mac)

---------------------------------------------------------------------------

From:       David.J.Ferbrache <[e-mail]>
Date:       Wed, 29 Mar 89 10:03:02 BST
Subject:    Disinfectant for Mac

Ken,

you asked about disinfectant. In my opionion this is probably the most
comprehensive virus control program available for the Mac system. The
program is designed to detect all non-hypertext Mac viruses (including
the recent AIDS resource edited nVIR strain). Most importantly this
program can detect the new Anti virus (see recent posting by Danny
Schwendener) which a number of older tools fail to detect [No
characteristic resource additions].

If run together with an INIT to detect modification of code file
resources (hmm, vaccine, gatekeeper, watcher etc one of this group),
it should provide excellent protection.

Availability:

Disinfectant 1.0 was posted to comp.sys.mac recently, and is available
from a number of backbone archive sites, including the info-mac
archives, and Heriot-Watt's anti-virus software archive.

I suspect Werner Uhrig's archives on RASCAL.ICS.UTEXAS.EDU should also
also have a copy in the virus-tools directory (although I haven't
confirmed this).

European sites can pull a copy by sending mail to
<[e-mail]> with the body:

request: virus
topic: mac.disinfect

Bugs:

One serious problem due to contention while accessing files from
remote servers, involving missed directories. John's looking into the
problem at the moment.

Features:

- - Detects and repairs files infected by Scores, nVIR A, nVIR B, Hpat,
  AIDS, INIT 29, ANTI, and MacMag.  These are all of the currently known
  Macintosh viruses.
- - Scans volumes (entire disks) in either virus check mode or virus
  repair mode.
- - Option to scan a single folder or a single file.
- - Option to "automatically" scan a sequence of floppies.
- - Option to scan all mounted volumes.
- - Can scan both MFS and HFS volumes.
- - Dynamic display of the current folder name, file name, and a thermometer
  indicating the progress of a scan.
- - All scans can be cancelled at any time.
- - Scans produce detailed reports in a scrolling field.  Reports can be
  saved as text files and printed with an editor or word processor.
- - Carefully designed human interface that closely follows Apple's
  guidelines.  All operations are initiated and controlled by 8 simple
  standard push buttons.
- - Uses an advanced detection and repair algorithm that can handle partial
  infections, multiple infections, and other anomalies.
- - Careful error checking.  E.g., properly detects and reports damaged and
  busy files, out of memory conditions, disk full conditions on attempts
  to save files, insufficient privileges on server volumes, and so on.
- - Works on any Mac with at least 512K of memory running System 3.2
  or later.
- - Can be used on single floppy drive Macs with no floppy shuffling.
- - 8500 word online document describing Disinfectant, viruses in general,
  the Mac viruses in particular, recommendations for "safe" computing,
  Vaccine, and other virus fighting tools.  The document can be saved as
  a text file and printed with an editor or word processor.  We tried to
  include everything in the document that the average Mac user needs to
  know about viruses.

John Norstad wrote Disinfectant with the help of an international group
of Mac virus experts, programmers and enthusiasts: Wade Blomgren,
Chris Borton, Bob Hablutzel, Tim Krauskopf, Joel Levin, Robert Lentz,
Bill Lipa, Albert Lunde, James Macak, Lance Nakata, Leonard Rosenthol,
Art Schumer, Dan Schwendener, Stephan Somogyi, David Spector, and
Werner Uhrig.

- --------------------------------------------------------------------------
Dave Ferbrache                            Personal mail to:
Dept of computer science                  Internet <[e-mail]>
Heriot-Watt University                    Janet    <[e-mail]>
79 Grassmarket                            UUCP     ..!mcvax!hwcs!davidf
Edinburgh,UK. EH1 2HJ                     Tel      (UK) 031-225-6465 ext 553

------------------------------

Date: Wed, 29 Mar 89 13:39 EST
From: "Mark H. Anbinder" <[e-mail]>
Subject: RE: Star Trek virus

There WAS one problem with the Star Trek: The Next Generation episode
"Contagion" as far as the treatment of computer viruses was concerned.
How did this alien code get executed?  If the Enterprise downloaded
the other ship's log as data, no code buried within it should have
been executed.

My speculation was that ship's logs include code (perhaps security
systems) that must be executed in order to accesss the data, so the
virus code could have been executed that way.

Mark H. Anbinder

------------------------------

Date:         Wed, 29 Mar 89 13:53:20 EST
Sender:       Virus Alert List <[e-mail]>
From:         [e-mail]
Subject:      PKWare virus? (PC)

Original-Date: Wed, 29 Mar 1989  10:50 MST
Original-From: Keith Petersen <[e-mail]>

Mark, I hope whoever posted messages on this will retract them
immediately.  There is NO virus and PKWare is NOT involved.

Here is the REAL story:

2/25/89 - ARCMASTER SOFTWARE DANGER
- -----------------------------------

The ArcMaster compression program shell/menu system has been a very
popular download on our BBS.  In the past week I have received
numerous reports of messed up hard disks after running ArcMaster
version 4.0 and 4.01.  I don't know if there were bugs in those
versions, or if some hacker has decided to target ArcMaster for
trojans.

I suggest all users of ArcMaster 4.0 and 4.01 stop using those
versions and wait until you can get a clean, new version from a
reliable source.

My apologies to John Newlin, since he has written some great software,
but the reports of trashed hard disks have been consistent enough to
warrant some caution with the 4.x versions of ArcMaster.

Bob Mahoney     Exec-PC Multi-user BBS  414-964-5160

------------------------------

Date:         Wed, 29 Mar 89 16:52:00 EST
From:         Joe McMahon <[e-mail]>
Subject:      Not really an nVIR (Mac)

The KillVirus INIT installs what I've called a "killed" virus - an
nVIR 10 resource that some (but not all) versions of nVIR check for.
If nVIR finds this resource in the system file, it "goes dormant" and
doesn't infect that copy of the System.

Generally, NOT RECOMMENDED. It triggers the detectors (as you've seen)
and interferes with Vaccine, You should remove the nVIR 10 resource
from any System whose system folder you've installed Kill- Virus and
make sure that KillVirus is out of there too.

Vaccine is safer and works as well.

 --- Joe M.

------------------------------

Date:         Wed, 29 Mar 89 16:59:52 EST
From:         Joe McMahon <[e-mail]>
Subject:      Disinfectant (Mac)

Disinfectant comes from John Norstad, someone whose work I would very
much trust. If John says it cleans up all that stuff, it does.

The only other thing I'd like to mention is that as viruses get more
complex, the less I trust disinfectants. I'm all for using them to
clean up far enough to finish what you're doing and THEN clean up by
replacing, but I wouldn't bet the farm on them.

 --- Joe M.

------------------------------

Date: Wed 29 Mar 89 13:22:09-PST
From: Ted Shapin <[e-mail]>
Subject: New England J. of Med. letter

New England Journal of Medicine, March 23, 1989, Vol. 320, No. 12,
page 811-12.  _COMPUTER-VIRUS INFECTION OF A MEDICAL DIAGNOSTIC
COMPUTER_

To the Editor:

Computers used in dianostic imaging, intensive care monitoring, and
other such functions have been relatively immune to computer
vandalism, because they have been special purporse units that are not
easily programmed by amateurs. A detailed MEDLINE search has revealed
no previous reports of "infection," or sabotage, of medical diagnostic
data with a computer "virus."
 Recently, our Department of Nuclear Medicine acquired new
image-display stations for cardiac studies, consisting of powerful
personal computers (PCs) (Macintosh II) that provide high-quality
images for diagnosis. After sucessfully using the system for several
weeks, we noted occasional random malfunctions. Often the computer had
to be shut down and then restarted before it would respond to any
commands. Occsionally, nonexistant patients and garbled names appeared
on the patient directory. We found that approximately 70 percent of
the programs on the PC data disk had been altered by the insertion of
an exogenous code into the standard computer instructions. In
addition, many new files were found scattered among the legitimate
programs. We found that our system harbored two separate computer
viruses. An investigation revealed that these viruses had spread from
a computer company to both our facilities (located 20 miles aprt) and
a nearby university medical center PC network.
 The computer virus has many similarities to biologic viruses. It is a
small program designed to splice copies of itself into other programs.
Whe these programs are run, the viral code directs the computer to
make additional copies of the virus and splice them into other
"uninfected" programs. The original program then continues aftera
barely noticeable delay. As with biologic viruses, host facilities are
subverted into producing endless copies of the foreign intruder. At
random intervals, these hidden programs may produce delays, noises,
scrambling, or actual deletion of data from computer storage.  The
viral infection may spread from computer to computer by the simple
insertion of a floppy disk into an infected machine and later into
another, similar computer. This is the likely mechanism of spread of
the viruses we encountered. Floppy disks used by members of our staff
for word processing were found to contain copies of at least one of
these viruses. After several weeks of meticulous work, all copies of
the virus were eliminated from our systems.
 Mass production of PCs has generated a large pool of amateur
programmers, a few of whom attempt computer sabotage either as an
intellectual challenge or as vandalism. The capability of the PC to
perform literature searches, word processing, and other tasks tempts
users of hospital PCs to insert a variety of "foreign" disks, thus
spreading infections. We now examine all software before use in our
systems and have alerted our personnel to the need to practice "safe
computing". As multipurpose PCs replace their safer single-purpose
predecessors in patient care, the need for expanded vigilance is
clear.

Jack E. Juni, M.D.
Richard Ponto
William Beaumont Hospitals
Royal Oak, MI 48072-2793
- -------

------------------------------

Date:         Wed, 29 Mar 1989 13:34:11 EST
From:         Clare Shawcross <[e-mail]>
Subject:      KillVirus Init not malevolent

A couple of postings have been made recently about KillVirus Init, one
(from Jonathan Baker) wondering if it was a virus or virally infected,
and the other (from David Stodolsky) suggesting that it is some sort
of breeding ground for viruses.

In fact, KillVirus Init is intended to *protect* your files from nVIR
by "vaccinating" your disk.  KillVirus contains a dummy nVIR and
installs one in your System file.  Interferon and VirusRX can't tell
the difference between this and a real virus.  But your Macintosh can.
And so can you.  One way of checking is to run a smarter program like
Disinfectant which will not flag the dummy virus.  The commercially
available program Virex will go so far as to flag such a virus as a
fake one.

The more adventurous may want to use ResEdit to look at the nVIR
resource on a file.  If it is called "InstallTrap (ID=1)" or "nVIR
Inhibitor (ID=10)" then you are dealing with a dummy virus rather than
the real thing.

Clare Shawcross
Consulting Support Specialist
Brown University

------------------------------

From:       Andrew Dawson <[e-mail]>
Date:       Thu, 30 Mar 89 10:31:54 BST
Subject:    Re: KillVirus Init (Mac)

The KillVirus Init is *NOT* infected with the nVIR virus - it just
appears that way to a lot of virus search utilities. A feature of nVIR
is that it will effectively disable itself if it finds an nVIR
resource with ID=10 in the system file. If you place killvirus in your
system folder and reboot, it will install an nVIR 10 resource in the
system to prevent infection, at the same time removing any other nVIR
resources. In order to do this effectively, killvirus itself has an
nVIR 10 resource, which is simply copied. There is no code in this
resource. Most virus checking utilities check for resources of a
certain type - and the presence of any nVIR resource will cause
warnings from Interferon, Virus RX or Virus Detective (and probably
others).

While I'm not actually very keen on anything that modifies the system
file, KillVirus has proved very effective in keeping our machines
clean - it will automatically disinfect any nVIR infected application
that a user attempts to launch.

Andrew Dawson
School of Medicine Computer Unit
University College London

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest             Thursday, 30 Mar 1989        Volume 2 : Issue 77

Today's Topics:
several reports available via anonymous FTP
Anti viral software and known viruses
Arcmaster: here is the explanation (PC)

---------------------------------------------------------------------------

Date: Thu, 30 Mar 89 09:02:38 EST
From: [e-mail] (Kenneth R. van Wyk)
Subject: several reports available via anonymous FTP

Over the last couple of weeks, I've received several technical reports
from various people.  I'd like to announce their availability.
Currently, they're only available via anonymous FTP from
lll-winken.llnl.gov, but I hope to have them on our LISTSERV shortly,
for BITNET users (FTP is for Internet users only).

Available are:

Coping With Computer Viruses and Related Problems
  by David M. Chess and Steve R. White
     IBM T.J. Watson Research Center
  filename: ibm.paper

Net Hormones: Part 1
Infection Control Assuming Cooperation Among Computers
  by David S. Stodolsky, PhD.
  filename: net.hormones

Virus 101 - Chapters 1,2,3 (would someone please send me chapter 4?)
  by George Woodside
  filenames: virus101.1, virus101.2, virus101.3

These files are all in the ~ftp/virus-l/docs directory on
lll-winken.llnl.gov.

Special thanks to all those who worked on these documents!  Your
efforts are *greatly* appreciated!

Enjoy,

Ken

------------------------------

Date:       Thu, 30 Mar 89 16:22:41 BST
From:       David.J.Ferbrache <[e-mail]>
Subject:    Anti viral software and known viruses

A quick request, as you may know Jim Wright's in the process of trying
to establish a network of co-operating server sites each of which are
prepared to create a directory of anti-viral software for one or
machine types.

Each server site would then share anti-viral software, with regular
notices of newly available software, index lists and note of the
methods of obtaining software being published on the virus lists, and
probably on the comp.sys groups.

Anyhow, now the request, I would be very grateful for details of where
the following anti-viral programs can be obtained, preferably from an
email based server :-

IBM PC

  Cop        command obfuscation processor
  Ice        intrusion countermeasure electronics (Cyberpunk anyone?)
  Ifcrc      CRC checker
  Novirus    file size monitor
  Trojan stop disk request interceptor
  Xficheck   crc and file attribute checker

MAC

  Agar       petri dish for viruses
  Nomad, nVIR weapons, nVIR assassin

Amiga

  clkdoctor, killvirus, sentry, viewboot, protection, tcell

I will be publishing a list of known viruses in mid-April together
with reviews of known protective software, the provisional virus list
now includes 11 IBM PC reported strains:

    Lehigh (2 variants),
    Brain (alias: Lahore, Pakastani; numerous variants),
    Italian (alias: Bouncing Ball, Ping Pong),
    Yale (relationship with Alameda virus to be established)
    Alameda (alias: Merritt)
    Austrian (alias: 648, Vienna),
    New Zealand (alias: Stoned),
    Cascade(alias: second austrian, blackjack, 1701, 1704),
    Friday 13th (alias: 1808, 1813, 1792, Israeli, Hebrew University, PLO,
        sUMsDos; also the sURIV 3.01 variant)
    April 1st (2 strains sURIV 1.01, sURIV 2.01)
    Dbase (based on Ross's recent report, awaiting confirmation)

    Hmm, two basic viruses appearing in Computer viruses: a high
tech disease, plus two other viruses developed as personal projects by
various people and never release (thank goodness!).

For the Mac, 7 strains:
    MacMag (alias: Peace, Drew),
    nVIR   (4 variants: nVIR A, nVIR B, Hpat and AIDS)
    Scores (alias: Vult),
    INIT 29,
    Anti,
    2 hypertext viruses: Dukakis, Hypertext avenger (Don't know
    much about this, only going by one of Alan Solomon's papers)

For the Amiga, 9 strains (including a few anti-virus viruses):
    Swiss crackers association, IRQ, Byte Bandit, Byte Warrior,
    Revenge, Obelisk softworks crew,
    [ North Star, Pentagon Circle, SystemZ - anti-viruses]

For the Atari ST, 11 strains (including 1 anti-virus virus):

    info mainly from George Woodside's virus killer program,
    Anti, Blot, Freeze, Mad, Screen, Key, ACA, Anti, Mouse inverter

    and from the Virus destruction utility:
    Milzbrand link virus

    also known to exist a family of viruses produced by the Virus
    construction set available at a recent German computer fair.

For the Atari 8 bit series:
    1 alleged virus (no details as of yet)

For the Apple II system, 4 strains:
    Elk cloner, festering hate, Cyberaids and Zlink

For a grand total of 44 discernable strains which are (or in some
extinct cases wer)e in circulation, I guess with about 57 if you count
variants as separate viruses. A list of this kind by its very nature
cannot be comprehensive, but I would be exceptionally grateful for
information on any viruses which do not appear on the above list, and
on any aliases you use for the above viruses which I have not cited.

And PLEASE, PLEASE how about some consensus regarding the terms used
to name viruses (especially IBM PC), the proliferation of aliases does
no-one any good and just serves to muddy the water. So far we have
named viruses by characteristic growth in file length, transient
memory usage, strings found in code, originating country, major
infections, resources added, obvious screen symptoms, oh and alleged
writer!

Oh, thanks to Y.Radai for the corrections on my report about the April
1st strains. Hopefully, it won't be quite as prolific as the Friday
13th.

It is my intention to disassemble a number of the more common viral
strains in the near furture to cross-check the reports published on virus-l,
comp.sys groups et al. The next list will include a classification of each
virus by its mode of operation, brief description of symptoms and available
disinfection software. Anyone else compiling a similar list please get in
touch so we can arrange to pool information, any reports of infections by
viruses not appearing on the above list would be of particular interest.

PS.Any more news about the so called Russian virus?


- ------------------------------------------------------------------------------
-
Dave Ferbrache                            Personal mail to:
Dept of computer science                  Internet <[e-mail]>
Heriot-Watt University                    Janet    <[e-mail]>
79 Grassmarket                            UUCP     ..!mcvax!hwcs!davidf
Edinburgh,UK. EH1 2HJ                     Tel      (UK) 031-225-6465 ext 553

------------------------------

Date: Thu, 30 Mar 89 11:50:24 EST
From: [e-mail]
Subject: Arcmaster: here is the explanation (PC)

Original-From: [e-mail] (Bruce M. Felstein)
Original-Subject: Re: Virus warning

The supposed bugs in ARCMASTER version 4xx and higher do not exist. If
people would bother to read the doc files they would have learned that
the directory that you specify for it to use to unarc and arc files to
MUST be a special blank directory, since it will erase the entire
contents of the directory after it finishes rearchiving the file. If
you didn't bother to read the docs you might specify your root
directory to use for this function and after ARCMASTER was done, it
would automatically erase all files in that directory.

Bruce Felstein          Microelectronic Center of NC
N3DOD                   Research Triangle Park, NC
[e-mail]

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest              Friday, 31 Mar 1989         Volume 2 : Issue 78

Today's Topics:
Disinfectant 1.0 (Mac, was Re: Disinfect 1.0)
4PLAY EXEC (IBM VM/CMS Trojan horse)
Macintosh Virus AIDS nVIR

---------------------------------------------------------------------------

Date: 29 Mar 89 12:12 +0200
From: Danny Schwendener <[e-mail]>
Subject: Disinfectant 1.0 (Mac, was Re: Disinfect 1.0)

>A colleague just showed me a program, called Disinfect (version 1.0)
>that was announced in INFO-MAC.  It claims to do quite a bit,
>including detect most major Mac viruses (Scores, ANTI, AIDS, Init 29,
>MacMag, etc.), and it is even supposed to be able to remove most
>(all?) of the above.
>Anyone Mac people out there have any more info on this?

Disinfectant detects and removes all the currently known code-based
viruses (there are script-based viruses, like the Hypercard Dukakis
virus, which won't be touched by this program). It also removes
multiple infections, which is an innovation in the virus fighting
world.  The user interface is simple, the on-line documentation
extensive and accurate. And, furthermore, it is free. Its author is
John Norstad ([e-mail]).

It has a minor problem in conjunction with servers: moving or deleting
files on the server while Disinfectant is browsing through the
directories may cause the program to skip some files. This problem is
common to most disk browsers. Nevertheless, the author is working on
the problem. The current solution to the problem is to disconnect or
write-protect the server for other users while Disinfectant is
running.

The current version is configured for following viruses: MacMag (aka
Peace, Drew, FreeHand, etc.), Scores, nVIR A and B as well as its two
name mutations Hpat and AIDS, INIT29 and ANTI. If you have the founded
impression that a virus is missing in the list, drop me or John a mail.
The 'Sneak' virus has only been rumored. No one who claimed having
seen it has been able to found his claims.

- -- Danny
+-----------------------------------------------------------------------+
| Mail    :  Danny Schwendener, ETH Macintosh Support                   |
|            Swiss Federal Institute of Technology, CH-8092 Zuerich     |
| Bitnet  :  macman@czheth5a      UUCP   :   {cernvax,mcvax}ethz!macman |
| Internet:  [e-mail]   Voice  :   yodel three times          |
+-----------------------------------------------------------------------+

------------------------------

Date: 30 March 1989 16:01:47 CST
From: Mark S. Zinzow   <MARKZ@UIUCVMD>
Subject:  4PLAY EXEC (IBM VM/CMS Trojan horse)

Another Trojan EXEC!

Original-Date:         Thu, 30 Mar 89 10:37:50 EST
Original-Sender:       BITNIC TECHREP List <TECHREP@BITNIC>
Original-Subject:      Security situation on network


            IMPROPER EXEC with UNETHICAL Embedded CODE
          Causes Possible SECURITY Situation on Network

An EXEC that contains questionable code has been discovered on the
network--the EXEC is a sexually oriented game called "4PLAY" which
apparently has existed for 18 months.

Embedded within the code are commands that record all console activity
which is then collected and sent to a specific network userid.  This is
done without the knowledge or consent of the person activating this code
(that is, playing the game).  This presents an obvious intrusion of
privacy and also a "security hole".

The security problem arises in that the EXEC does not close the
CONSOLE.  (If it did, the user would receive a message allowing her or
him to to detect the recording of information entered.) The result is
that console activity continues to be recorded after the completion of
the game and UNTIL the user actually LOGs off the account.
Consequently, the unsuspecting user may be transmitting other data as
well, that is, any confidential data that the console processes in
line mode will be recorded, possibly compromising security: passwords
could be transmitted.

When the user signs off the userid accessing this EXEC, the capturing
of all console activity ceases.

THE USE OF COMPUTER NETWORKS TO OBTAIN INFORMATION WITHOUT THE PRIOR
KNOWLEDGE AND CONSENT OF THE USER IS UNETHICAL.

THE USE OF BITNET FOR TRANSMITTING SUCH GAMES AR THIS IS NOT WITHIN
BITNET's MISSION TO ENHANCE EDUCATION AND RESEARCH.


If you are aware that this software exists on your system, the BITNIC
encourages you to contact the persons responsible for your system and
alert them to the situation and the need for removal of this software.

The following action to curtail such activity, taken by the node that
identified the problem, may be helpful to you in guarding against such
network misuse:

Immediately--remove the offending software and warn users.
Long term----use a security system (if you have one) to permit only
authorized id's to send spool data or files beyond your node.

------------------------------

Date:         Fri, 31 Mar 89 13:40:46 MET+0100
Sender:       Virus Alert List <[e-mail]>
From:         [e-mail]
Subject:      Macintosh Virus AIDS nVIR

AIDS Warning

Macintosh Virus.
AIDS spreads using applications and system.
nVIR clone !!!!!

I do not know, if someone reported this virus already.  Some one
changed all ASCCI strings 'nVIR' to 'AIDS'.  So the AIDS virus is
nVIR. Fast way to get rid of the virus is the following.

Get a copy of ANTIPAN, and a file editor, SUM, MacTools or FEdit,
change all nVIR strings in ANTIPAN to AIDS, and your problem is
solved. If the resource 'CODE' id 0 is locked or protected, the
ANTIPAN program does not remove the virus. Unlock or unprotect the
resource using ResEdit

Jo van Bilsen
ACCU Utrecht Nederland (Holland)
ACMJOJO@HUTRUU0

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest              Friday, 31 Mar 1989         Volume 2 : Issue 79

Today's Topics:
RE: The Star Trek virus.
Re: Arcmaster bug (PC)
Disinfectant 1.0 Bugs (Mac)
Hypercard based viruses... (Mac)
How can I get into VIRUS-L archives
administrative message (please read)

---------------------------------------------------------------------------

Date:     Fri, 31 Mar 89 09:13 EST
From:     Morton Downey Jr. for President. <[e-mail]>
Subject:  RE: The Star Trek virus.

     There's been some mention of the Star Trek: The Next Generation
episode "Contagion".  The episode seemed to me to be an attempt to
educate people about viruses.  What the episode said to me was, that
while viruses can be potentially dangerous (i.e. it destroyed the
Yamato), the solution to them is fairly simple (a shut down of the
Enterprise computer, clean out effected memory, then a restart).  This
seems to be a much better way to discuss the problem than the
sensationalism that goes on when viruses are discovered.

Tom Kummer

------------------------------

Date:         Fri, 31 Mar 89 09:35:24 EST
From:         "Peter G. Rose" <[e-mail]>
Subject:      Re: Arcmaster bug (PC)

>>The supposed bugs in ARCMASTER 4xx do not exist.     ...
>>the directory that you specify for it to use to unarc and arc files to
>>MUST be a special blank directory   ...
>>[If you] specify your root directory ... it would automatically erase
>>all files in that directory.

Ok, its not a bug, its a design error.   It's STILL wrong.   If the damn
thing is going to require its own special blank directory, why doesn't
it create its own?
                                       P.Rose

[Ed. If the problem was actually due to a design error, as appears to
be the case, then it is a problem unrelated to viruses that should be
taken up with the author of Arcmaster.]

------------------------------

Date:    Fri, 31 Mar 89 10:46:24 EST
From:    [e-mail]
Subject: Disinfectant 1.0 Bugs (Mac)

Disinfectant 1.0 has been released for about a week and a half now,
and for the most part it seems to be working well.  There have been a
few bug reports, however, and I want to let you know that I'm working
on a 1.1 release to fix them.  It will be at least a few weeks before
I release it.  I want to wait a bit until I'm certain that we've
discovered all the problems in 1.0.  Until then, watch out for the
following problems.

Some kinds of "damaged" files could cause version 1.0 to hang, bomb,
or put up its "out of memory" alert.  Version 1.1 will do a better job
of checking for damaged files.  If you get a bomb, hang, or out of
memory alert while scanning with 1.0, try removing the file that was
being scanned from your disk and then scan the disk again.

Scanning an active server disk in 1.0 is problematic.  If other users
create or delete files or folders while the scan is in progress, it
can sometimes cause other files or folders to be skipped or scanned
twice.  This is a problem shared by almost all programs which scan
disks.  We've designed and implemented an improved disk scanning
algorithm for 1.1 to avoid this problem.  Note that in any case we
continue to recommend that you take servers out of production to scan
them.  This is the only way to avoid file busy errors and insufficient
privileges errors.

Version 1.0 evidently doesn't work at all over a TOPS network.  We'll
try to find out why and fix it if possible.  For now you should not
attempt to scan non-local disks over TOPS.

Disinfectant works on unenhanced 512K Macs with System 3.2 or later,
but it requires the "Hard Disk 20" file.  We overlooked this in our
testing of version 1.0.  Version 1.1 will check to make sure this file
is present, and issue an alert if it is missing.

Version 1.0 doesn't properly display its icon in the Finder, because
we forgot to set the "bundle bit" when we shipped the program.  This
stupid mistake will be fixed in 1.1.

If you run 1.0 on a GateKeeper-protected system to try to repair
infected files, and if you forgot to add Disinfectant to GateKeeper's
list of privileged applications, you will get "unexpected" error
messages.  In 1.1 we will try to special-case these errors and issue a
better message that mentions GateKeeper explicitly.

We received reports that in some cases Disinfectant claims that a file
is infected, even when other virus tools report that the file is
uninfected (e.g., Virus Rx 1.4a1 and Virus Detective).  This is
possible, since Disinfectant uses stronger checks than most of the
other tools.  The files sent to us were indeed partially infected, but
not contagious.  We'll document this possibility in version 1.1.

The version 1.1 document will correct a few minor typos and errors,
and we'll add a "Version History" section.

Thanks to everybody who's written about Disinfectant - I enjoy and
appreciate your notes.  Special thanks to those people who have
reported bugs.

John Norstad
Academic Computing and Network Services
Northwestern University

Bitnet:      jln@nuacc
Internet:    [e-mail]
AppleLink:   a0173
CompuServe:  76666,573

------------------------------

Date: Fri, 31 Mar 89 11:17:38 EST
From: [e-mail]
Subject: Hypercard based viruses... (Mac)

Original-To: [e-mail]

In your message entitled "Anti viral software and known viruses", you
referenced two Hypercard viruses, "Dukakis" and "Hyperavenger".  If I
am not mistaken, there is one Hypercard virus, known as "Dukakis",
written by the self-proclaimed "Hyperavenger"

David Gursky, W143
Member of the Technical Staff
Special Projects Department
The MITRE Corporation

------------------------------

Date: Fri, 31 Mar 89 14:54 CST
From: Chris Garrigues <[e-mail]>
Subject: How can I get into VIRUS-L archives

I just discovered that one of our Macs got infected by the "SCORES"
virus.

Since I'm not generally interested in viruses, I don't subscribe to
the list, but in this case, I'd like to look at your archives to
search for messages on this subject.  How can I do this?

(Or could someone just forward me anything I need to know?)

Chris Garrigues,
Systems manager,
Schlumberger Laboratory for Computer Science

[Ed. This comes up periodically, so I thought I'd include it here.
VIRUS-L archives are available via anonymous FTP from
IBM1.CC.LEHIGH.EDU (in weekly format) and from lll-winken.llnl.gov (in
per-digest format).  BITNET readers can get to the archives by sending
mail (or interactive message) to LISTSERV at LEHIIBM1 (*NOT* VIRUS-L
at LEHIIBM1).  The message should read:

GET VIRUS-L LOGyymmx

where "yy" is the year (88, 89...), mm is the month (01...), and x is
a letter corresponding to the week of the month (A, B,...).  So, the
archive file for the second week of March, 1989 is VIRUS-L LOG8903B.]

------------------------------

Date: Fri, 31 Mar 89 16:39:04 EST
From: [e-mail] (Kenneth R. van Wyk)
Subject: administrative message

Greetings all,

VIRUS-L is now up to just about 1200 direct subscribers.  Among other
things, this means that the amount of bounced mail (due to computers
or networks being down, disk quotas exceeded, etc.) gets to be pretty
major here.  The most common cause of this is when an account gets
removed from a machine, I get a message back saying "user unknown" for
every digest that goes out.  It's not uncommon for me to get 30 such
messages in a day.  (Violins start playing...*:)  Sometimes, bounced
messages snowball.  For example, some mail relays try to connect for 3
days, and then send back a bounced message once every 3 days for 12
days.  Needless to say, the information flow can be high.

What to do...  If the message is obviously due to a permanent thing,
such as a user being removed from a system, then I remove the address
from the list.  If the message could be due to an intermittent
problem, such as a network link being down, then I give that address a
day or two to clean up its act.  Having failed that, I remove the user
from the list.

The moral to this long sob story is this: if you've not received any
digests in quite a while (a week or so), and/or if you know that your
e-mail system was down for a period of time, you may well have gotten
removed from the list, not because I'm out to get you, but because I
have to try to keep bounced mail (read: time) to a minimum.  If this
happens, please understand, and re-subscribe (if you wish to rejoin
the list, that is...).  (I'll add this to the "welcome" message for
new subscribers.)

Ken

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest            Wednesday, 26 Apr 1989       Volume 2 : Issue 100

Today's Topics:
UK computer virus conference
Yale and 1701/1704 virus, and Sentry (PC)
Re: Using Checkfunctions For Virus Detection (General Interest)
more on Flu_Shot+ availability (PC)

---------------------------------------------------------------------------

Date:    Tue, 25 Apr 89 22:41:51 BST
From:    David.J.Ferbrache <[e-mail]>
Subject: UK computer virus conference

                   Combatting Computer Viruses
                   ---------------------------

There will a one day conference (sponsored by PC Business world) held on
the 17th May 1989, in the City conference centre, London.

The agenda for the conference is enclosed:

0930   What is today's computer virus
       Jim Bates, Consultant Programmer, Bates Associates
       Introductory session, characteristics of viruses,
       demonstration of live viruses (Italian, Brain, New Zealand)

1030   The networking perspective
       Mark Gibbs, Manager, Corporate marketing, Novell Inc
       Network virus propogation. Management and technical measures
       to prevent propogation.

1150   The legal position,
       Jeffrey Chapman, consultant to the Law commission
       Existing and propsed legislation. Actions to recoupe damages.

1400   Keeping out the virus - The US experience
       Ross Greenberg, owner software concepts design
       Management procedures and software used in prevention of viruses

1505   How paranoid do you want to be?
       Alan Solomon, Chairman IBM PC user group.
       Personal prospective on virus control, including emphasis on
       an organisation awareness of the dangers. Supportive case studies.

1600   Virus forum

The conference package includes distribution of disks with anti-viral
software. The price is 235 pounds + vat. Enquiries to:

Jenny Mann, Quadrilect,
46 Gray's Inn Road, London WC1X 8PP
Telephone [phone]
Fax       [phone]

The conference seems from their program to be aimed primarily at business
and corporate users, with limited experience of systems programming or
virus prevention.

If I can afford to attend (!) I will be writting a review for comp.virus
of the conference, and of the available protective software.

- -------------------------------------------------------------------------
Dave Ferbrache                       Internet   <[e-mail]>
Dept of computer science             Janet      <[e-mail]>
Heriot-Watt University               UUCP       ..!mcvax!hwcs!davidf
79 Grassmarket                       Telephone  [phone] ext 553
Edinburgh, United Kingdom            Facsimile  [phone]
EH1 2HJ                              BIX        dferbrache
- -------------------------------------------------------------------------

------------------------------

Date:    Tue, 25-Apr-89 15:14:25 PDT
From:    portal!cup.portal.com![e-mail]
Subject: Yale and 1701/1704 virus, and Sentry (PC)

There seems to be some confusion about whether the Alameda/Yale virus
can infect ATs or other 286 systems.  I worked on the original Alameda
College infection and the virus at that time was unable to work on any
286 system.  The reason is that it contained an invalid 286
instruction (POP CS), which is not a legal op code.  A 286 will
normally hang up if this op code is in the executable file.  Two
months after the Alameda infection, though, a new strain showed up
that was able to infect 286 systems, using a different relocation
technique.  This newer strain is identical in every respect to the
original strain, with this single exception.

Also, there seemed to be some confusion about the difference between
the 1701 and 1704 viruses.  Mr. David Chess stated that the 1704 virus
could not successfully avoid infecting IBM systems, and that he had
tested that aspect himself.  If that is the case, then he has tested
the 1701 virus, not the 1704 virus.  The 1701 is the precursor to the
1704.  It had a bug in the BIOS check routine, and infected IBM
systems anyway.  The1704 is three bytes longer and has been verified
by dozens of sites to successfully avoid infecting IBM systems.  Mr.
Goodwin's decompilations of the two viruses points out these
differences.

Finally, I would like to comment on Mr. David Bader's remarks about
the Sentry program.  I have been using various versions of Sentry for
almost a year and I couldn't ask for better protection.  It's clear
that Mr. Bader has had limited exposure to live viruses.  Anyone who
has worked with a broad range of viruses could not arrive a the
conclusions he stated.

------------------------------

Date:    Tue, 25 Apr 89 20:28:06 -0400
From:    Joe Sieczkowski <[e-mail]>
Subject: Re: Using Checkfunctions For Virus Detection (General Interest)

A friend of mine saw [e-mail]'s message on the above
subject and had the following comment in response to it.  I thought it
was appropriate for the list.

>His checksum might be harder to fake, but it is not necessary to be able
>to reverse the encryption to fake a checksum.  Only the algorithm for
>the forward encryption is needed, and that can be pulled from the
>program that does the checking.  If f is the checksum and g is the
>encryption, all he has done is create a new function s(x) = f(g(x))
>which is just another signature function.  If f was more than just
>a CRC polynomial, g might not really make any difference, and if
>f is a CRC, then some choices of g could make the combination easier
>to break.
>                                                               WB

Joe

------------------------------

Date:    Wed Apr 26 12:49:15 1989
From:    utoday![e-mail]
Subject: more on Flu_Shot+ availability (PC)

Hey folks!  I guess I forgot to mention that I have to get those
requests for the freebie FLU_SHOT's in writing!  I know it sounds
horrid and all that, but my fufillment stuff requires paper copies
(boo! hiss! old technolgy!)

Here's my paper address again for those of you who need it:
   Ross M. Greenberg
   Software Concpets Design
   594 Third Avenue
   New York, New York 10016

Thanks!

Ross

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest             Thursday, 27 Apr 1989       Volume 2 : Issue 101

Today's Topics:
Forwarded Message From Jim Goodwin re: various VIRUS-L comments
BRAIN infection (PC)
More Using Checkfunctions For Virus Detection (General Interest)
re: Yale and 1701/1704 virus, and Sentry (PC)
re: Checkfunctions For Virus Detection (General Interest)

---------------------------------------------------------------------------

Date:    Thu 27 Apr 1989 06:00 CDT
From:    GREENY <[e-mail]>
Subject: Forwarded Message From Jim Goodwin re: various VIRUS-L comments

The following is a message that I am forwarding for Jim Goodwin on the
HomeBase Virus BBS.

Bye for now but not for long
Greeny

BITNET: MISS026@ECNCDC
Internet: [e-mail]

 ------------------------- Message Test to Follow -------------------------
04/25/89 08:26:59 (Read 18 Times)
From: JIM GOODWIN

Last weeks Virus-L messages brought up a number of good points and questions.
I hope the following clarifies some of the issues:

To David Chess: Mr. McAfee is correct when he states the POP CS
instruction will not work on 286 machines - in real or protected mode.
As Naama Zahavi-Ely of the Yale computer center verified, the Yale
(Alameda) virus does not run on ATs or other 286 machines.  In fact,
the the only way this virus is discovered (usually) is when someone
attempts to boot a 286 machine from an infected disk.  There is,
however, another version of the Yale (Version -C), that replaces the
POP CS with another series of instructions used to relocate the virus
in memory.  This version will run on the 286.  Perhaps this is the
version that you mean.

To Tom Sheriff: The virus you described is the Australian virus (or
stoned virus).  It is a boot sector infector and causes no damage.
The message you described is on the boot sector but it is never
displayed.  If you like, you can obtain a disassembly of the virus
from HomeBase.  Leave me a message.  BTW, to remove the virus, perform
a SYS command on the affected disks.

To David Bader: You are incorrect about Sentry.  It does not modify
any existing files, the documentation warns of the re-boot and it does
display the names of all infected files.  As to the interrupt vector
modifications, Sentry installs first in the autoexec, so no other
programs will have been loaded that modify the interrupt vectors.  We
have yet to find a virus that Sentry will not detect.

To Jeff Scott: The virus that you describe is the Venezuelan virus.
It is a boot sector infector and is a damaging virus.  There is also a
non-virus Trojan floating around that looks identical from a user
standpoint.  To determine whether you have the trojan or the virus,
boot a system diskette on an infected machine and check the boot
sector using Norton to see if it has been modified.  If it has, then
you have the viral version.

To David Chess: You mentioned a bug in the 1704 virus that prevents it
from recognizing true IBM machines.  What you are describing is the
1701 virus.  The 1701 is identical to 1704 with the exception that
1701 cannot recognize the IBM/Clone difference.  IBM in Denmark was
the first company to get hit by the 1701, and there is a joke going
around that the 1701 went into IBM, and the 1704 came out.  By the
way, both the 1701 and the 1704 can recognize pre-existing infections,
but they WILL re-infect each other.

Just a note of interest.  I have finished the disassembly of the
Russian Black Hole virus, and find that it is merely the New Jerusalem
with some non-referenced text additions.  Anyone wishing to see the
disassembly please contact me on Homebase.  408 988 4004.

Jim Goodwin.

------------------------------

Date:    Thu, 27 Apr 1989 01:02 IST
From:    Ilan Lamdan <[e-mail]>
Subject: BRAIN infection (PC)

It seems like I have a visitor...
A (c) brain virus infected few of my diskets.
I wonder if anybody can tell me :
      A. any harm done by this virus... (what to expect ?)
      B. any cure ?
      C. if so, how can I get it (no ftp, pure BITNET).
         I searched the <msdos.trojan-pro> on SIMTEL20
         but found nothing.

                                       thanks in advance
                                                Ilan

------------------------------

Date:    Thu, 27 Apr 89 08:38:52 EST
From:    [e-mail]
Subject: More Using Checkfunctions For Virus Detection (General Interest)

In Virus-L V2 #100, Joe Sieczkowski <[e-mail]>
passed on the following comment regarding my suggestion of encrypting
the input to a checkfunction algorithm in order to prevent a virus
from masking itself by having no effect on the checkfunction:

>His checksum might be harder to fake, but it is not necessary to be able
>to reverse the encryption to fake a checksum.  Only the algorithm for
>the forward encryption is needed, and that can be pulled from the
>program that does the checking.  If f is the checksum and g is the
>encryption, all he has done is create a new function s(x) = f(g(x))
>which is just another signature function.  If f was more than just
>a CRC polynomial, g might not really make any difference, and if
>f is a CRC, then some choices of g could make the combination easier
>to break.
>                                WB

Before I go on, let me note that I understand "WB"'s comment about
faking the checksum to mean that the virus is somehow able to
recalculate the checksum for the application after infection.  My
solution was meant to address the case of a virus that, once added to
an application, would not affect the checkfunction value.

To address WB's comments (does this person have a name?  I dislike
using initials for someone I've never met), you need more then just
the encryption algorithm, you need the encryption key as well.  While
I did say the key should be dependent on the data to be encrypted,
that does not preclude the use of an independent seed key left up to
the user.  This seed is then modified by the input data.  Even if the
virus has the clear input data, and the encryption algorithm, it would
need to query the user to get original seed key to success- fully
infect the application.

David Gursky
Member of the Technical Staff, W-143
Special Projects Department
The MITRE Corporation

------------------------------

Date:    27 April 1989, 10:28:07 EDT
From:    David M. Chess  <[e-mail]>
Subject: re: Yale and 1701/1704 virus, and Sentry (PC)

I stand corrected on "POP CS"; that's what I get for reading (and
misinterpreting!) the manual, rather than trying it myself.  "POP CS"
is invalid on a '286, even in real (DOS) mode, and the version of the
virus with POP CS in it shouldn't be able to function on '286
machines.  My mistake!

On the "vanilla IBM machine" issue, though, I stick to my guns.  I
have samples of both the 1701 and the 1704.  The 1701 has *two* bugs
in that section: he forgot the "ES" overrides, and the last compare is
a word compare rather than a byte compare.  He fixed the override bug
in the 1704, but he still has the word-compare bug.

Perhaps I'm missing something subtle here.  It seems to me that the
instructions

.     CMP   WORD PTR ES:[DI+8],4DH
.     JZ    KILLVIRUS

Are testing for the value "004D" at that place in BIOS.  Interpreted
as bytes, that's an "M" followed by a byte of zeros.  In all the
vanilla IBM machines I've looked at, the "M" is in fact followed by a
blank (020 hex).  So the compare will fail, and the jump to KILLVIRUS
will not be taken.

Have I made a mistake there somewhere?   I have tested the 1704 on
a number of vanilla IBM machines, and it happily infects on all of
them.   Perhaps there are some clones on which the "M" in "IBM"
is actually followed by 00?   Doesn't seem too likely...

In any case, unless you can point out some mistake in the above,
I think we have to conclude that the virus author still has a
bug, and that the 1704 does spread just as well on vanilla IBM
machines as on anything else.

DC

------------------------------

Date:    27 April 1989, 10:39:06 EDT
From:    David M. Chess  <[e-mail]>
Subject: re: Checkfunctions For Virus Detection (General Interest)

I don't think the conclusion was that check functions are too easy to
defeat!  A simple-minded fixed CRC has definite problems, but there
are at least two alternatives to that (I thought they both came up in
the discussion, but they may not have):

  - Use a more complex algorithm, based on an encryption (as you
    suggest).   CRCs were designed to detect accidental changes,
    and no one was worried about the computational complexity of
    inverting them.   Now that we *are* worried about that, it
    makes sense to use what's been learned in the crypto area.
    As you say, that can be slow.  If hardware-assists for crypto
    become common, that would help!

  - Use a CRC in which the polynomial is kept secret.   If the
    CRC is long enough (30 bits seems a good lower bound), and the
    polynomial is actually kept secret, it becomes very very hard
    to invert the CRC.   I don't think anyone shot down that idea
    in the previous discussions, except to note that keeping the
    polynomial away from the virus reliably requires care.

DC

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest              Friday, 28 Apr 1989        Volume 2 : Issue 102

Today's Topics:
Missouri Virus (PC)
Net Hormones Paper by David S. Stodolsky
Trojan REXX EXECs (VM/CMS)
Problem in BASIC virus related? (PC)

---------------------------------------------------------------------------

Date:    Thu, 27-Apr-89 13:57:27 PDT
From:    portal!cup.portal.com![e-mail]
Subject: Missouri Virus (PC)

The Homebase group has logged over a dozen occurrences of this virus
but we have never successfully sampled it.  The latest occurrence was
notable enough to pass on to Virus-L so that we might get some
assistance.  The occurance was at the National Security
Administration.  The virus came into their shop on a disk shipped with
the book - "DOS Power Tools", published by Bantam.  This was the third
report of the virus entering an installation on this book.  The virus
completely disables writing to the hard disk, but it does allow normal
reading of data already stored.  Every site that has been hit has
destroyed or lost the original source disk, and the target disk.  The
NSA is no exception.  Robert Dimsdale of the NSA in Fort Meade
originally reported the virus to the CVIA and he cut the floppy into 8
sections prior to calling.  He then disrarded the standard CVIA advice
and low level formatted the hard disk.  Anyone with any additional
information about this virus is invited to share that information with
what we already know by contacting the HomeBase board.  We know that
Missouri is a virus and not a Trojan because we have documented four
occurances of its replication.  Please do not contact Mr. Dimsdale
directly.  Serious inquiries should be addressed through Jim Corwell
on Homebase.  He will pass on your name to the NSA and they will
reply.

Another report that came in on the same day, co-incidentally, involved
another book called - "Using Application Software" from Random House.
It was reported at Florida International University, contact name -
Mitchel Zidel.  We have not yet followed this one up.  If any of you
folks would like to join the Sleuth Team, contact Jim and sign up for
this one.  He has the phone number and specifics.

P.S. A number of HomeBase users would like to communicate with
Virus-L.  They are all, however, local BBS users and none (with one or
two exceptions) have access to Usenet or Bitnet.  How can I go about
posting their mail on Virus-L?

------------------------------

Date:    Fri, 28 Apr 89 11:59:11 MDT
From:    Chris McDonald <[e-mail]>
Subject: Net Hormones Paper by David S. Stodolsky

I read with interest the subject paper which resulted in some questions.

First, if contact tracing is technically possible among hosts and
networks, is the proposed "theory of operation" described in paragraph
4 of the paper really practical?  Dr. Stodolsky proposes that: "In the
event that a system is identified as infected, the transaction codes
which could represent transactions during which the agent was
transmitted are broadcast to all other computers."  The words "which
could represent transactions" suggests that an attack which used a
delay mechanism or "time bomb" approach would make it extremely
difficult to identify suspect transactions in a timely manner.  It
might also suggest that the historical record of transactions would of
necessity be inordinately large and for practical reasons might be
difficult to implement.

Second, even though Dr. Stodolsky stresses that the contact tracing
operation would alert a system to the "possibility" of an agent's
presence, does this represent a significant improvement over other
more conventional means to broadcast alerts of a potential problem, as
is now done over the Internet?  For example, if I were running a BSD
version of UNIX last November, the tcp-ip broadcast alert--assuming
the gateways were still up and functioning--might have been adequate
to respond to the Internet Worm.  If "contact tracing" had been
available, however, would not non-BSD UNIX systems have received
"alerts" which would have caused unnecessary concern?

Third, if the alert through contact tracing is to "restrict further
transmission of the agent," is not cutting off communications among
hosts on a network the only practical solution pending further
investigation?  If so, do we not have the mecahnism to do that now,
however imperfectly?

Chris McDonald
White Sands Missile Range

------------------------------

Date:    Fri, 28 Apr 89 15:42:58 EDT
From:    "Gregory E. Gilbert" <[e-mail]>
Subject: Trojan REXX EXECs (VM/CMS)

I have noticed that a number of "mischievious" (? spelling) EXECs
(VM/CMS) capture information in the NAMES file on one's disk and
forward themselves to users listed in one's names file.  Is there any
way to prevent this (forwarding) from occuring should, by chance and
unknowingly, an EXEC be invoked?

[Ed. How about renaming (or encrypting) your names file all the time,
except when you're in MAIL or MAILBOOK?  Not elegant, perhaps, but
probably effective.]

------------------------------

Date:    Fri, 28 Apr 89 15:52:35 EST
From:    Mignon Erixon-Stanford <[e-mail]>
Subject: Problem in BASIC virus related? (PC)

      One of our guys wrote a BASIC file which reads one ASCII
file and writes it out to another ASCII file (just a different
arrangement of the data.) The interpreter & compiled versions
worked perfectly at our main site (on PS/2 Model 60).

      Same guy went to outlying research facility.  The interpreter
version ran fine (on AT machine).  Guy did a DIR B: of disk 1 which
contained data files.  Then Guy did DIR B: of disk 2 (which contained
a basic compiler).  The FAT of disk 2 got overwritten by ASCII
characters of file info about disk 1.

      We could not recreate the error on the AT nor back at our
main site.  This sounded like a problem with the buffers,
so i Suggested they:

      increase # files & buffers in CONFIG.SYS;
      boot from back-up copy of original DOS disk & do a SYS C: ;
      set file attribute on COMMAND.COM to READ ONLY;
      check for viruses;
      have tighter controls on what software is put on machine.

But if any of you folks out there have other suggestions, please write me.
Thanks.

                      Mignon Erixon-Stanford, Smithsonian Institution
                      otherwise known as IRMSS907 @ SIVM

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest             Saturday, 29 Apr 1989       Volume 2 : Issue 103

Today's Topics:
Mac Write Protection
Administrative message (& reason for short digest)

---------------------------------------------------------------------------

Date:    Fri, 28 Apr 89 16:57:41 EDT
From:    "Gregory E. Gilbert" <[e-mail]>
Subject: Mac Write Protection

Is Apple working on a mechanism to write protect hard drives via
hardware?  If so what's the time-table?  Any other comments on the
subject would be most welcome.

------------------------------

Date:    Sat, 29 Apr 89 15:27:21 EDT
From:    [e-mail] (Kenneth R. van Wyk)
Subject: Administrative message (& reason for short digest)

I will be out of town until Thursday, so please don't send me messages
saying, "What happened to VIRUS-L".  We will resume the digests on
Thursday.  In the meantime, please feel free to continue to
contribute.  I'll digestify all of the incoming messages upon my
return.

On a side note, news readers may be interested to know that comp.virus
should be operational shortly after my return.  Those readers who get
Usenet news at their sites will probably want to opt for reading
VIRUS-L via the comp.virus newsgroup.

Ken

------------------------------

End of VIRUS-L Digest
*********************

VIRUS-L Digest             Wednesday, 5 Apr 1989        Volume 2 : Issue 80

Today's Topics:
Possible Trojan Horse...
Coping With Computer Viruses and Related Problems
CSI Program for Virus '89
VirusDetective (Mac)

---------------------------------------------------------------------------

Date: Mon, 03 Apr 89 09:01:04 EST
From: [e-mail]
Subject: Possible Trojan Horse...

Several bulleting boards in the Washington DC metropolitan area have
had a "Stuffit 2.0" uploaded to them.  This does not appear to be a
legitimate update to Ray Lau's Stuffit utility.  A cursory check of
the "Get Info" box will show some rather funky information in the
application name and version fields.

We (myself and the Sysops of the boards that have had this uploaded
to) have no evidence that this utility does anything harmful, but then
again, why would someone upload a bogus version of Stuffit.

David Gursky, W-143
Member of the Technical Staff
Special Projects Department
The MITRE Corporation

------------------------------

Date: 3 April 1989, 11:41:52 EDT
From: David M. Chess   <[e-mail]>
Subject: Coping With Computer Viruses and Related Problems

Thanks for making the report available, Ken!  The full reference
is something like

Coping With Computer Viruses and Related Problems
  by Steve R. White, David M. Chess and Chengi Jimmy Kuo
     IBM T.J. Watson Research Center
     IBM Los Angeles Scientific Center
     Research Report (RC 14405) January 30, 1989

(Three authors!)

Abstract
          We discuss computer viruses and related problems.  Our
          intent is to help both executive and technical managers
          understand the problems that viruses pose, and to suggest
          practical steps they can take to help protect their
          computing systems.

It's also available (in ARC format) as VIRUSD.ARC in LIB 0 (at
the moment) of the IBMSYS forum on CompuServ.

While it's written for a management-type audience, general users
should find it interesting as well.   Except for one appendix
(which describes some places in PC-DOS that should be watched for
viruses), it's very non-specific, and applies to any sort of
computer.

DC

------------------------------

Date: Tue, 04 Apr 89 14:03:07 EST
From: Gene Spafford <[e-mail]>
Subject: CSI Program for Virus '89

I dunno if this has already been sent out and if it is appropriate for
VIRUS-L, but here it is:


           COMPUTER VIRUSES '89 at the IBM & DEC Users Conference
               May 1-3, 1989 * Hyatt Regency O'Hare * Chicago
                  Sponsored by Computer Security Institute

                              PROGRAM OVERVIEW


Partial list of speakers addressing virus-related topics:

     Eugene H. Spafford, Purdue University, will present an in-depth
          analysis of the Internet worm incident.

     Michael Karels, head of UNIX development at UC Berkeley, will
            discuss how UNIX is meeting the virus challenge.

     Kenneth R. van Wyk, creator of Lehigh University's VIRUS-L bulletin
          board, will talk about lessons learned.

     Richard D. Pethia, Carnegie Mellon University, will describe the
          first DARPA CERT (Computer Emergency Response Team), which he
          heads.

     Davis McCown, prosecutor in the "Texas Virus Trial" which
          convicted Donald Gene Burleson in September 1988, will
          recount the investigation and the trial.

- -----------------------------------------------------------------------------
Demonstrations of viruses, hacking, bulletin boards:

     Ross Greenberg, author of FLU_SHOT+, will demo viruses and describe
          PC Magazine's evaluation of 11 anti-virus products.

     Thomas V. Sobczak of Application Configured Computers will
          demonstrate hacking, underground bulletin boards, virus
          behavior, and public domain solutions.

     John McAfee, Computer Virus Industry Association, will demonstrate
          virus and anti-virus programs and present new statistical
          information on viruses.

- -----------------------------------------------------------------------------
Information on new security-related products:

     CA-ACF2/VAX and CA-Top Secret/VAX, which can help unify security and
          access control in mixed IBM-DEC shops.

     ClydeSentry, LJK/Security, Secure Pak, and The Security Toolkit,
          for assessing and monitoring security in DEC environments.

- -----------------------------------------------------------------------------
Exhibition -- A wide range of computer security products will be
displayed
    during this two-day show.

Workshop Orientation -- 42 half-day sessions; attendees choose two
    each day




                             PROGRAM DETAILS


COMPUTER VIRUS WORKSHOPS

 1. Computer Viruses: Background, Detection,      John McAfee, Computer Virus
    and Recovery                                  Industry Association

 2. Applying Traditional Management Techniques    Roger Shaw,
    to Controlling Computer Viruses               IBM Corp.

 3. Protecting Against Unauthorized System        Albert H. Decker,
    Attacks                                       Coopers & Lybrand

 4. Virus Emergency Response                      Richard Pethia, Software
                                                  Engineering Institute,
                                                  Carnegie Mellon University

 5. Virus-Resistant Networked Unix System         Michael J. Karels, Univ.
                                                  of California, Berkeley

 6. Viruses and Worms--What Can You Do?           Stanley A. Kurzban,
                                                  IBM Corp.

15.  Policies and Procedures for Controlling      John G.  O'Leary,
    the Virus Threat                              Computer Security Institute

16.  A Technical Analysis of the Internet Worm    Eugene H.  Spafford,
    Incident                                      Purdue University

17.  Practical Risk Management Techniques for     Robert V.  Jacobson,
    Controlling Computer Viruses                  International Security
                                                  Technology, Inc.

18.  An Evaluation of Anti-Virus PC Software      Ross M.  Greenberg,
                                                  PC Magazine

19.  Legal & Insurance Issues of Computer         Robert W.  Baker, Jr.,
     Viruses                                      Weinberg and Green

20.  Managing a Virus Awareness Program           Nicholas M.  Elsberg,
                                                  Aetna Life & Casualty

29.  System Attack Demonstrations                 Thomas V.  Sobczak, Ph.D.,
                                                  Application Configured
                                                  Computers (ACC,Inc.)

30.  The Successful Prosecution of Donald Gene    Davis McCown, Tarrant
    Burleson: A Case History                      Cty (TX) Dist Atty's Ofc

31.  Setting the Record Straight on Computer      Robert H.  Courtney, Jr.,
    Viruses                                       RCI

32.  Lessons Learned from Computer Viruses        Kenneth R.  van Wyk,
                                                  Lehigh University

33.  Auditing Techniques for Controlling Viruses  Michael Thayer,
                                                  Price Waterhouse

34.  Computer Viruses and Your Disaster Recovery  Edward S.  Devlin,
    Plan                                          Harris Devlin Associates

- -----------------------------------------------------------------------------
IBM-SPECIFIC WORKSHOPS

 7. Overview of IBM Security                      Curtis L. Symes, IBM Corp.

 8. Using CA-ACF2 to Protect Against Computer     Georgene Piper, Computer
    Viruses                                       Associates International

 9. Controlling Security Risks of Personal        James P. Dwyer, Blue Cross
    Computers                                     Blue Shield of Maryland

10.  Comparing the Security Review Process in     Emily Lonsford,
    IBM and DEC Environments                      The Mitre Corp.

21.  AS/400 Security and Control                  Wayne O.  Evans, IBM Corp.

22.  RACF Overview                                Robert W.  Spitz, IBM Corp.

23.  Network Security for an IBM Environment      William H.  Murray,
                                                  Ernst & Whinney

24.  Introducing CA-ACF2/VAX                      Dan Wilkinson, Computer
                                                  Associates International

35.  Living with DB2 Security                     Martin G.  Hubel,
                                                  The Systems Center

36.  Using CA-Top Secret to Protect Against       Kimberly Bell, Computer
    Computer Viruses                              Associates International

37.  Auditing MVS and VM System Software          F. J.  (Phil) Dolan,
                                                  IBM Corp.

38.  Managing Security in a Large-Scale IBM       John Blackley, Capital
    Environment                                   Holding Corporation

- -----------------------------------------------------------------------------
DEC-SPECIFIC WORKSHOPS

11.  Overview of Digital Security Features and    Steve Bold,
    Products                                      Digital Equipment Corp.

12.  Introduction to VAX/VMS Security             Edward J.  Norris,
                                                  Digital Equipment Corp.

13.  Managing a Comprehensive Security Program    Robert J.  Melford,
    in a DEC Environment                          R.J. Melford Associates

14.  Security for Networked VAX/VMS Systems       Geoff Cooke,
                                                  DEMAC Software

25.  Mapping VAX/VMS and IBM Mainframe Security   Colin C.  Rous, Digital
                                                  Equipment of Canada

26.  Advanced VAX/VMS Security                    Pamela Kelly,
                                                  Digital Equipment Corp.

27.  Security Tools for Safeguarding the DEC      Adolph F.  Cecula, Jr.,
    Environment: A Panel                          Bureau of the Census

28.  Building Applications Security on            Andy Goldstein,
    Operating System Security                     Digital Equipment Corp.

39.  Introducing CA-Top Secret/VAX                Kurt Seibert, Computer
                                                  Associates International

40.  DECnet Security                              Lawrence J.  Kilgallen,
                                                  Software Consultant

41.  The Ethernet Security System                 Jeffrey R.  Sebring,
                                                  Digital Equipment Corp.

42.  A Checklist Approach to Auditing             Pat McGovern,
    VMS Security                                  Bankers Trust Company


For more information, Contact:

                   Van McGuirk    [phone]
                   Computer Security Institute
                   360 Church Street
                   Northborough, MA 01532

------------------------------

Date:         Tue, 04 Apr 89 21:17:52 EST
From:         Steve Rocke <[e-mail]>
Subject:      VirusDetective (Mac)

     Is anybody familiar with the Mac desk accessory VirusDetective?
How reliable is it?  Does it merely identify infected files or will it
also remove viruses from files?

     If anybody has experience with it, I would like to hear from you.
Thanks.

     Steve Rocke
     Central Michigan University
     BITNET address:  34JIOMV@CMUVM
Acknowledge-To: <34JIOMV@CMUVM>

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest             Thursday, 6 Apr 1989         Volume 2 : Issue 81

Today's Topics:
Hard Disks and Viruses
Virus Detective (Mac)
Something to ponder...

---------------------------------------------------------------------------

Date:         Sat, 01 Apr 89 09:34:15 EDT
From:         Swifty Le-Bard <[e-mail]>
Subject:      Hard Disks and Viruses

Greetings to all!
   To all the people who have contributed answers to an unfortunate
common problem, thanks, I needed that! But anyway, I am planning on
purchasing a HD (71mb) and would like some suggestions as to how I can
spot a virus (or potential one), and if dreadfully, I do encounter
one, what can I do short of erasing all the data.
   The viruses I speak of are the kind that wind up on the boot
sector, and those that work on COM and EXE files. Do the viruses stay
resident on one area of the Hard Disk, or do they move around?  (copy
itself to other partitions, and/or subdirectories).

          Thanks for any info/answers!

                 )--==*>PHOENIX<*==--(

------------------------------

Date: Wed, 05 Apr 89 15:55:25 EST
From: [e-mail]
Subject: Virus Detective (Mac)

>     Is anybody familiar with the Mac desk accessory VirusDetective?
>How reliable is it?  Does it merely identify infected files or will it
>also remove viruses from files?

Under the expectation that by "reliable" you mean "successfully detect
a virus", Virus Detective is very reliable for detecting MacMag/Peace,
nVIR/Hpat (and I suspect the AIDS variant of nVIR), Scores, Init 29,
and ANTI.  In order to detect the latter two viruses, you will need
version 2.1.1.

For eradication, you will either have to do this manually, or obtain
another product (a recent one that holds alot of promise is
Disinfectent.  Refer to the March 30 Virus-L digest for the details on
it).

Virus Detective 2.1.1 and Disenfectant 1.0 are both archived by the
InfoMAC people.  I suggest you ask there for details on how to
transfer these utilities to your local machine.

Disclaimer:  Dis is soup.  Dis is Art.  Soup.  Art.

David M. Gursky
Member of the Technical Staff, W-143
Special Projects Department
The MITRE Corporation

------------------------------

Date: Wed, 05 Apr 89 18:18:30 EST
From: [e-mail]
Subject: Something to ponder...

I've been doing some research on viruses here at the office and I
thought struck me, perhaps someone on InfoMAC or Virus-L can
contribute something to this:

The Brain virus that afflicts MS-DOS systems has the capability to
infect the bootstrap code on a floppy disk.  This makes it a
particularly nasty virus because a "warm restart" will not cause the
virus to go away; it will still be in the bootstrap code that is kept
in RAM.

My question is this: Why can't the bootstrap code on tracks 0 and 1 of
a Mac disk be infected?  Would Vaccine prevent such an infection?

My suspected answers are (1) it can be done and (2) no, Vaccine would
be totally ineffective against it.

If my suspicions are indeed correct, how likely is it that Don Brown
could be persuaded to update Vaccine to prevent this?

David M. Gursky
Member of the Technical Staff, W-143
Special Projects Department
The MITRE Corporation

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest             Thursday, 6 Apr 1989         Volume 2 : Issue 82

Today's Topics:
A New Virus Perhaps (PC)
Bad, Bad, Bad Boot Blocks (Mac)
Mac Boot Sector Virus -scary thought
WARNING: ORGASM EXEC (VM/CMS)
ORGASM EXEC siting in Florida (VM/CMS)
Cornell RTM Worm Report

---------------------------------------------------------------------------

Date:         Thu, 06 Apr 89 13:36:26 MEZ
From:         Ghost <[e-mail]>
Subject:      A New Virus Perhaps (PC)

     We have possibly found a new virus. It's characteristic is a
string named "Packed file is corrupt". It can be found in PCTOOLS and
other programs. New buyed program discs are infected, but till now he
didn't do anything. It is about 900 Byte long and ends with the upper
string. Does anyone heard of him or does anyone has it in his
software??

Thomas Friedrich, RHRZ Bonn, Germany

------------------------------

Date:         Thu, 06 Apr 89 08:58:31 EDT
From:         Joe McMahon <[e-mail]>
Subject:      Bad, Bad, Bad Boot Blocks (Mac)

Well, from looking in general at the history of Mac viruses so far,
they've followed Apple's implementation guidelines remarkably well :-).

The viruses all used standard Mac facilities in a slightly nonstandard
way to reproduce and spread; the ANTI virus (the most recent one) is
the first to do anything different, and that one *still* doesn't
really do anything exceptional.

The boot blocks are a different matter. As I recall, part of the
"bootstrap" code is in the ROM (the blinking-question-mark disk) and
part on the disk itself. I also don't believe that there are calls
like MessWithBootBlocks(); you'd have to get down there at the device
level and mess with it. Not that this couldn't be done, it's just much
harder that diddling another virus with ResEdit and releasing it.

 --- Joe M.

------------------------------

Date: Thu,  6 Apr 89 13:03:20 CDT
From: "David Richardson, UT-Arlington" <[e-mail]>
Subject: Mac Boot Sector Virus -scary thought

David M Gursky ([e-mail]) writes:

>My question is this: Why can't the bootstrap code on tracks 0 and 1 of
>a Mac disk be infected?  Would Vaccine prevent such an infection?

Good question, scary.  I am forwarding his original msg to
[e-mail].

As configured, Vaccine would definately *NOT* stop it, and there is no
current detection for this type of infection (other than by hand with
FEdit or the like).

- -David Richardson,                    The University of Texas at Arlington
Bitnet: b645zax@utarlg            Internet:  [e-mail]
UUCP:     ...!{ames,sun,texbell, <backbone>}!utarlg.arl.utexas.edu!b645zax
SPAN:     ...::UTSPAN::UTADNX::UTARLG::b645ZAX      US Mail: PO Box 192053
PhoNet: [phone] (FREE from Dallas, TX)    Arlington, TX 76019-2053

------------------------------

Date:     Thu, 6 Apr 89 15:28 EDT
From:     <[e-mail]>
Subject:  WARNING: ORGASM EXEC (VM/CMS)

*** WARNING *** WARNING *** WARNING *** WARNING *** WARNING *** WARNING ***

An exec file known as ORGASM was released about two days ago on the
PSUVM system.  This file was obviously written up here, and was
detected by Computer center personnel soon after it was released.  It
sends null messages to all users linked to a particular disk and then
sends the file to all users listed in the names file it finds.

Up to this point I believed that we had a local outbreak....the file
was written with Penn State in mind...probably by a student.  However,
I just got done talking with another person down at University of
Central Florida, and she reports that a copy was found at her
location.  Therefore, I am now assuming that this program has spread
across BITNET.

I just felt that everyone on this list should be warned of the
possible problems in letting this program spread.

Jonathan Baker                      JEB107 at PSUVM.BITNET
                                    The Pennsylvania State University.

DISCLAMER : I am just a student...not an employee.  I am doing this only
            to keep the community infomed about possible problems.

[Ed. Jonathan later sent me the following message that was posted by
the Penn State computing center warning its users of the EXEC.  Thanks
to all for the prompt reports!]

Date: Tue, 04-Apr-89, 16:07:30 EDT
From: "Al Williams" <[e-mail]>
Subject: IMPROPER PROGRAMS BEING DISTRIBUTED ON PSUVM

A program called ORGASM EXEC is being distributed, and might be found
in your reader (RDRLIST) or on mindisks you link and access.  DO NOT
RUN THIS PROGRAM.  DISCARD it from your reader, or ERASE it from your
disk.

It may do some things without warning you, and does at least two
things programs should not do: it sends a null message via RSCS
(resulting in "...")  to all or most logged-on users, and it mails a
copy of itself to all users listed in your NAMES file.  The message is
annoying to recipients and should be embarrassing to you.  Mailing out
copies should also be embarrassing, but more importantly wastes
resources and has the potential of "clogging" our system and others we
are connected to.

Distributing or providing access to any program that acts in a
surreptitious manner is considered an invalid use of your computer
account and in violation of University policies.  While you may not
realize what a program does, you are responsible if you execute it.
If you are not sure a program behaves properly, DISCARD IT!

ALW

------------------------------

Date:         Thu, 06 Apr 89 16:24:48 EST
From:         Lois Buwalda <[e-mail]>
Subject:      ORGASM EXEC siting in Florida (VM/CMS)

Hello,

I've run across another one of those lovely viruses which goes by the
name of ORGASM EXEC.  It is disguised as a message server type utility
(approximately 1400+ lines long), with the virus itself relatively
cleverly hidden (the size of the file itself makes it difficult to
detect).  The virus is effective in only 2 instances:  1)  If the user
has a disk defined as virtual addr 319.  It queries all users connected
to this disk and propogates itself to them.  2)  If the site uses RXNAMES,
a Penn State University tool.  The EXEC then sends itself to all people
in the user's NAMES file.  It appears to be "safe" if these two conditions
are not met.

The virus originated at PSUVM, although at the time of this posting the
writer has not yet been caught.

Lois Buwalda
Systems Support
University of Central Florida

------------------------------

Date:     Thu,  6 Apr 89 13:45:04 PST
From:     [e-mail]
Subject:  Cornell RTM Worm Report

Just read in the April 3 _Unix Today_ that Cornell is releasing a report
today on the Internet Worm.  Does anyone know where I can get a copy?

Peter Scott ([e-mail])

------------------------------

End of VIRUS-L Digest
*********************
VIRUS-L Digest              Friday, 7 Apr 1989          Volume 2 : Issue 83

Today's Topics:
More thoughts on potential nasy Mac Boot Block virus (Mac)
Error in Thinking (PC)
re: A New Virus Perhaps (PC)
Zip "virus" isn't a virus (PC)

---------------------------------------------------------------------------

Date: Thu, 06 Apr 89 19:20:23 EST
From: [e-mail]
Subject: More thoughts on potential nasy Mac Boot Block virus (Mac)

In Virus-L, Joe McMahon ([e-mail]) wrote...

>Well, from looking in general at the history of Mac viruses so far
>they've followed Apple's implementation guidelines remarkably well :-).

When in Cupertino, do like Steve Jobs does... <Big Grin>

>The viruses all used standard Mac facilities in a slightly nonstandard
>way to reproduce and spread; the ANTI virus (the most recent one) is
>the first to do anything different, and that one *still* doesn't
>really do anything exceptional.

>The boot blocks are a different matter. As I recall, part of the
>"bootstrap" code is in the ROM (the blinking-question-mark disk) and
>part on the disk itself. I also don't believe that there are calls
>level and mess with it. Not that this couldn't be done, it's just much
>harder that diddling another virus with ResEdit and releasing it.

No question about it.  A Mac Boot Block virus (henceforth I'm going to
call this thing "the Sad Mac virus") would be sophisticated IMHO, but
I'm not 100% certain.  Correct me if I'm wrong, but does not the Mac
boot blocks contain the name of the file the ROM bootstrap should load
into RAM?  If this is the case, the Sad Mac virus would only need to
change this name to some other file, and voila', its infiltrated the
machine.  Yes, I'm grossly simplyfing things, but I've long since
retired from hacking.

On a related subject, suppose I went to the U.S. Copyright office, and
copyrighted the idea for the Sad Mac virus.  Does this mean that if
someone actually went and implemented it, they are prosecutable not
only under the Computer Infiltration Act (or whatever it is called),
but the Copyright Act?  Have I come up with a concept that can be
copyrighted?  I doubt it is patentable.

Disclaimer:  Good evening.  I'm David Gursky, and you're not.

David M. Gursky
Member of the Technical Staff, W-143
Special Projects Department
The MITRE Corporation

------------------------------

Date:         Fri, 07 Apr 89 11:24:53 MEZ
From:         Thomas Friedrich (Ghost) <[e-mail]>
Subject:      Error in Thinking (PC)

     Hi, there

i told of a new possible virus, but it was a mistake by me and other
people who haven't enough knowledge to check up. A system programmer
here told us today, that the string "Packed file is corrupt" is a
regular error code by the DOS program EXEPACK. It optimizes the memory
holding by a program and builds checksums. If starting such packed
program the machine loader unpacks this code and checks the sum, if
not correct this message will be returned.

In addition to that, sorry for my mistake using my pseudonym here.  My
MAIL EXEC did it automaticly, and i thought it wasn't so bad, but i
know now, that this wasn't a joke. Sorry!

Thomas Friedrich
University Bonn
Germany

------------------------------

Date:      7 April 1989, 14:20:07 EDT
From:      David M. Chess   <[e-mail]>
Subject:   re: A New Virus Perhaps (PC)

That's probably just the Microsoft EXEPACK utility.  It makes smaller
versions of EXE files by compressing them, and sticking on a small
decompresser program.  The decompresser contains the message that you
give, in case something has damaged the compressed version of the
original file.  It comes with many Microsoft compilers, and is not a
virus.

Of course, someone COULD have written a virus with that message in
it, just to lull us into trusting it...

DC

[Ed. Interesting utility - kind of reminds me of Fred Cohen's example
of a Compression Virus.]

------------------------------

Date:     Fri, 7 Apr 89 13:54:15 EDT
From:     Fred Hartmann <[e-mail]>
Subject:  Zip "virus" isn't a virus (PC)

I checked with Jerry Shenk, SYSOP of Lancaster Area Bulletin Board
(LABB) regarding the possible PKZIP virus and here are his comments:

"We have version .92 of PKZIP on-line here and we have version 4.2 of
AM.  The problem was not a virus.  PKZIP has a feature that will allow
it to pass a files attribute to the ZIP and when the file is unZIPped
it will keep that attribute.

This has had some rather surprising consequences none of which are
really a virus although they would hog up their share of disk space.
The problem was that a file could contain a hidden file (attribute set
to hidden - nearly everyone has at least two of these such files on
their system...placed there by DOS).  If these files are added to a
ZIP file and that ZIP gets unZIPped to a C:\DUMP and if that is the
directory that is normally used for ZIP unZIP operations the hidden
file(s) will be added to every ZIP that's made from that directory.
It would also be quite easy to pass those hidden files all over the
disk (ie. every place a file was unZIPped.

The primary perpetrators of this have been SYSOPs who are converting
files from ARC to ZIP and/or reZIPping for better compression.  I
happen to use a utility for disk management that displays all files
(hidden or not) so I would have spotted it if it had been happening on
LABB.

As I understand, Phil is working on a flag that will disable the
'hidden' flag so that ALL files would be visible if a user wanted it
done that way."

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest             Saturday, 8 Apr 1989         Volume 2 : Issue 84

Today's Topics:
VIRUS-L Guidelines???
Hard disk write-protection via hardware (PC)
More thoughts on potential nasy Mac Boot Block virus (Mac)
Russian Virus a practical joke (PC)
Cornell RTM Worm Report

---------------------------------------------------------------------------

Date:     Fri, 7 Apr 89 14:07:44 EDT
From:     Fred Hartmann <[e-mail]>
Subject:  VIRUS-L Guidelines???

What, if any, are the VIRUS-L guidelines regarding redistribution of
VIRUS-L email messages to a BBS?  Most BBS members appear to be
responsible individuals with a serious desire to learn about
computers.  Would it be appropriate to redistribute some or all of the
VIRUS-L email messages to them or would it only increase the chances
of someone using something appearing here to everyone's detriment?

[Ed. No problem with me.  Go right ahead.]

------------------------------

Date:    Fri, 07 Apr 89 14:55:07 CDT
From:    "Rich Winkel UMC Math Department" <[e-mail]>
Subject: Hard disk write-protection via hardware (PC)

Could some hardware hacker upload instructions on disabling the write
capability of an XT or AT style hard disk?  I believe it just involves
1 or 2 lines on the cable between the disk and controller.

Thanks,
Rich Winkel

[Ed. The problem with that is that the entire hard disk would be
read-only (which could be useful for some applications).  It would be
particularly useful IMHO to be able to set certain subdirectory trees
(e.g. \BIN) read-only, with hardware support.]

------------------------------

Date:    Fri, 7 Apr 89 22:49:25 EDT
From:    [e-mail] (Joe Sieczkowski)
Subject: More thoughts on potential nasy Mac Boot Block virus (Mac)

>On a related subject, suppose I went to the U.S. Copyright office, and
>copyrighted the idea for the Sad Mac virus.  Does this mean that if
>someone actually went and implemented it, they are prosecutable not
>only under the Computer Infiltration Act (or whatever it is called),
>but the Copyright Act?  Have I come up with a concept that can be
>copyrighted?

>David M. Gursky

What an interesting idea...Copyright a virus and give NO one
permission to use it. At least make the royalty high enough that no
one would want to violate it.

Unfortunately, there is a little draw-back here.  Ideas cannot be
copyrighted but the implementation of ideas can.  So you couldn't
copyright the idea of having boot-strap viruses, but you probably
could copyright a boot-strap virus that uses a particular method to
enter the system.  There might be many (possibly infinite)
permutations on one system, however another might have only a few.

Of course, we have to address the question of whether or not we want
people copyrighting viruses.  This has pros and cons.  On the one
hand, if many system people copyrighted viruses thereby exposing
security holes, better systems will be developed using this knowledge.
On the other hand, if every Tom, Dick, and Harry start developing
viruses to be copyrighted, a few might get loose (either intentionally
or otherwise) and cause havoc.

Hmmmmm....


Joe

[Ed. The Brain virus boot block contains a copyright notice.]

------------------------------

Date:    Fri, 7 Apr 89 22:59:17 EDT
From:    [e-mail] (Joe Sieczkowski)
Subject: Russian Virus a practical joke (PC)

The russian virus isn't a virus at all, it seems to be a joke.  After
receiving a copy of comand.com that was supposedly infected with the
russian virus, , I diff'ed it with a "clean" copy. The following
output appeared:

***** command.com
$ device
$Abort$, Retry$, Ignore$, Fail$? $
File allocation table bad,$
Invalid COMMAND.COM
$Insert disk with $ in drive
***** russian.bin
$ device
$You have just activated a Russian Virus...Thank You! .........
$Invalid COMMAND.COM
$Insert disk with $ in drive
*****

As you can see, it appears that all the author did was change the
"abort, retry, ignore" line with the russian virus message.

Of couse, never let anything like this fool you, the virus could
be in another program and just change this line in command.com.

Joe

------------------------------

Date:    Sat, 8 Apr 89 14:16:23 EDT
From:    A. M. Boardman <[e-mail]>
Subject: Cornell RTM Worm Report

>Just read in the April 3 _Unix Today_ that Cornell is releasing a report
>today on the Internet Worm.  Does anyone know where I can get a copy?

A general report was released from the Purdue Provost's office
recently, although for a technical report you should look at "The
Internet Worm Program: An Analysis",(Gene Spafford) Purdue Technical
report CSD-TSR-823, which can be FTP'd from arthur.cs.cpurdue.edu.
Other good references are Donn Seeley's paper and "With Microscope and
Tweezers; an Analysis of the Internet Worm of November 1988" from
someone of other at MIT.  Last time I checked, all three of these were
available for anonymous ftp from athena.ai.mit.edu.

Andrew Boardman, student at large, Columbia University
[e-mail], [e-mail], rutgers/uunet!columbia!cunixc!ab4

[Ed. The above reports are also available for anonymous FTP from
lll-winken.llnl.gov]

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest              Monday, 10 Apr 1989         Volume 2 : Issue 85

Today's Topics:
Re: Hardware write protection
Re: VIRUS-L Digest V2 #84
Re: Copyrighting a virus
HEADACHE EXEC (VM/CMS)
RE  WORM REPORTS WAS  CORNELL RTM WORM REPORT
Cornell's report on the Morris Worm (long)

---------------------------------------------------------------------------

Date:         Sat, 8 Apr 1989 15:34 EST
From:         Bruce Ide <[e-mail]>
Subject:      Re: Hardware write protection

If you do figgure out how to do this, you could probably set up a
toggle switch or key thing to alllow you to write to your disk
when it's switched one way and keep write protection on when it's
switched the other. If you want to keep users out, set it up with the
key. If it's to keep viri out, set it up with the switch. It'll take
a bit of soldering, and a few thirty nine cent swtiches from radio
shack. I did something similiar on my modem to switch pins two and
three with the flick of a switch.

------------------------------

Date: Sat, 08 Apr 89 16:17:55 EST
From: Gene Spafford <[e-mail]>
Subject: Re: VIRUS-L Digest V2 #84

>> Date:    Sat, 8 Apr 89 14:16:23 EDT
>> From:    A. M. Boardman <[e-mail]>
>> Subject: Cornell RTM Worm Report
>>
>> >Just read in the April 3 _Unix Today_ that Cornell is releasing a report
>> >today on the Internet Worm.  Does anyone know where I can get a copy?
>>
>> A general report was released from the Purdue Provost's office
>> recently, although for a technical report you should look at "The
>> Internet Worm Program: An Analysis",(Gene Spafford) Purdue Technical
>> report CSD-TSR-823, which can be FTP'd from arthur.cs.cpurdue.edu.

Correction:  the report is from the Cornell Provost's office, not
Purdue's.

My tech report has also appeared in "ACM Computer Communication
Review" (the SIGCOMM newsletter), and those of you without FTP access
can get a copy from there.  It was v19, #1 (Jan. 1989).

Further, the June or July issue of Communications of the ACM will have
a number of special articles on the Morris Worm, including one by me.

- --spaf

------------------------------

Date: Sat, 08 Apr 89 16:24:12 EST
From: Gene Spafford <[e-mail]>
Subject: Re: Copyrighting a virus

A copyright on a particular virus wouldn't help much.  Writing a virus
from scratch would be an original work and would not infringe the
copyright unless it included portions of the copyrighted work.  There
is also legal precedent for denying copyright on items you do not
intend to publish.  Copyrighting something and keeping it "secret" can
be grounds for voiding a copyright, in some cases, I believe.

A patent would provide more protection, but you would have to prove
that you had the original idea for it, and we're well over the time
limit that would allowed for filing for a patent, so either of those
approaches is also right out.

The real problem with either approach is that it only gives you
standing in civil court to sue for loss of revenue.  You would have to
identify the infringer and schedule a court case.  Then you'd have to
prove the infringement.  Not only would this be difficult to do, but
it would take a very long time and likely not result in anything you
could gain.  It would not prevent someone from writing or running a
virus.

Now if you want to indulge in the kind of short-sighted stupidity that
Apple is pursuing, you might try to copyright a virus "look-and-feel"
:-)

- --spaf

------------------------------

Date:         Sat, 08 Apr 89 20:10:47 EDT
From:         Ron Dawson <[e-mail]>
Subject:      HEADACHE EXEC (VM/CMS)

A new REXX program similar to the infamous XMAS EXEC is making the
rounds.  It appeared here at UOTTAWA on April 8.  It is called
HEADACHE EXEC and it pretends to be a chat program.  However, embedded
about 750 lines down in the code, it sends itself to everyone on your
names list.

Do not run this program......

- - Ron

------------------------------

Date:     Sun 09 Apr 1989 05:07 CDT
From:     GREENY <[e-mail]>
Subject:   RE  WORM REPORTS WAS  CORNELL RTM WORM REPORT

> ...ALL THREE OF THESE WERE AVAILABLE FOR ANONYMOUS FTP FROM
> ATHENA.AI.MIT.EDU [ED. THE ABOVE REPORTS ARE ALSO AVAILABLE FOR
> ANONYMOUS FTP FROM LLL-WINKEN.LLNL.GOV]

ALTHOUGH SEVERAL GRACIOUS SOULS HAVE SENT ME COPIES OF TWO OF THE
ABOVE PAPERS, WHAT WOULD BE THE POSSIBILITY OF SOMEONE ON THE INTERNET
SENDING A COPY OF EACH PAPER FOR POSTING TO THE LISTSERV?

THIS WOULD PROVIDE EASY ACCESS TO SOME INTERESTING, AND MUCH NEEDED
INFORMATION TO PERSONS ON THE BITNET...

BYE FOR NOW BUT NOT FOR LONG
GREENY

BITNET: MISS026
INTERNET: MISS026%ECNCDC.BITNET

[Ed. I'm working on that...]

------------------------------

Date: Sun, 09 Apr 89 18:06:39 EST
From: Gene Spafford <[e-mail]>
Subject: Cornell's report on the Morris Worm (long)

 ------- Forwarded Message

Original-Date:    Sun, 09 Apr 89 17:19:16 -0500
Original-From:    comer (Douglas Comer)
Original-Subject: a nice summary of the Cornell report

Summary by Manny Farber <[e-mail]>

The Cornell Chronicle is the Administration's organ.  As such, their
coverage of the Bob Morris report may be relatively one-sided, but
since they got the report in advance, they summarized it.  I'll put
the last paragraph right here: Copies of the report are available from
the Office of the Vice President for Information Technologies, 308 Day
Hall, [area code 607] 255-3324.

CORNELL PANEL CONCLUDES MORRIS RESPONSIBLE FOR COMPUTER WORM
(By Dennis Meredith, Cornell Chronicle, 4/6/89)

  Graduate student Robert Tappan Morris Jr., working alone, created
and spread the "worm" computer program that infected computers
nationwide last November, concluded an internal investigative
commission appointed by Provost Robert Barker.

  The commission said the program was not technically a "virus"--a
program that inserts itself into a host program to propagate--as it
has been referred to in popular reports.  The commission described the
program as a "worm," an independent program that propagates itself
throughout a computer system.

  In its report, "The Computer Worm," the commission termed Morris's
behavior "a juvenile act that ignored the clear potential
consequences."  This failure constituted "reckless disregard of those
probable consequences," the commission stated.

  Barker, who had delayed release of the report for six weeks at the
request of both federal prosecutors and Morris's defense attorney,
said, "We feel an overriding obligation to our colleagues and to the
public to reveal what we know about this profoundly disturbing
incident."

  The commission had sought to determine the involvement of Morris or
other members of the Cornell community in the worm attack.  It also
studied the motivation and ethical issues underlying the release of
the worm.

  Evidence was gathered by interviewing Cornell faculty, staff, and
graduate students and staff and former students at Harvard University,
where Morris had done undergraduate work.

  Morris declined to be interviewed on advice of counsel.  Morris had
requested and has received a leave of absence from Cornell, and the
university is prohibited by federal law from commenting further on his
status as a student.

  The commission also was unable to reach Paul Graham, a Harvard
graduate student who knew Morris well.  Morris reportedly contacted
Graham on Nov. 2., the day the worm was released, and several times
before and after that.

  Relying on files from Morris's computer account, Cornell Computer
Science Department documents, telephone records, media reports, and
technical reports from other universities, the commission found that:

  - Morris violated the Computer Sciences Department's expressed
policies against computer abuse.  Although he apparently chose not to
attend orientation meetings at which the policies were explained,
Morris had been given a copy of them.  Also, Cornell's policies are
similar to those at Harvard, with which he should have been familiar.

  - No member of the Cornell community knew Morris was working on the
worm.  Although he had discussed computer security with fellow
graduate students, he did not confide his plans to them.  Cornell
first became aware of Morris's involvement through a telephone call
from the Washington Post to the science editor at Cornell's News
Service.

  - Morris made only minimal efforts to halt the worm once it had
propagated, and did not inform any person in a position of
responsibility about the existence or content of the worm.

  - Morris probably did not indent for the worm to destroy data or
files, but he probably did intend for it to spread widely.  There is
no evidence that he intended for the worm to replicate uncontrollably.

  - Media reports that 6,000 computers had been infected were based on
an initial rough estimate that could not be confirmed.  "The total
number of affected computers was surely in the thousands," the
commission concluded.

  - A computer security industry association's estimate that the worm
caused about $96 million in damage is "grossly exaggerated" and "self-
serving."

  - Although it was technically sophisticated, "the worm could have
been created by many students, graduate or undergraduate ...
particularly if forearmed with knowledge of the security flaws
exploited or of similar flaws."

  The commission was led by Cornell's vice president for information
technologies, M. Stuart Lynn.  Other members were law professor
Theodore Eisenberg, computer science Professor David Gries,
engineering and computer science Professor Juris Hartmanis, physics
professor Donald Holcomb, and Associate University Counsel Thomas
Santoro.

  Release of the worm was not "an heroic event that pointed up the
weaknesses of operating systems," the report said.  "The fact that
UNIX ... has many security flaws has been generally well known, as
indeed are the potential dangers of viruses and worms."

 The worm attacked only computers that were attached to Internet, a
national research computer network and that used certain versions of
the UNIX operating system.  An operating system is the basic program
that controls the operation of a computer.

  "It is no act of genius or heroism to exploit such weaknesses," the
commission said.

  The commission also did not accept arguments that one intended
benefit of the worm was a heightened public awareness of computer
security.

  "This was an accidental byproduct of the event and the resulting
display of media interest," the report asserted.  "Society does not
condone burglary on the grounds that it heightens concern about safety
and security."

  In characterizing the action, the commission said, "It may simply
have been the unfocused intellectual meanderings of a hacker
completely absorbed with his creation and unharnessed by
considerations of explicit purpose or potential effect."

  Because the commission was unable to contact Graham, it could not
determine whether Graham discussed the worm with Morris when Morris
visited Harvard about two weeks before the worm was launched.  "It
would be interesting to know, for example, to what Graham was
referring to in an Oct. 26 electronic mail message to Morris when he
inquired as to whether there was 'Any news on the brilliant
project?'" said the report.

  Many in the computer science community seem to favor disciplinary
measures for Morris, the commission reported.

  "However, the general sentiment also seems to be prevalent that such
disciplinary measures should allow for redemption and as such not be
so harsh as to permanently damage the perpetrator's career," the
report said.

  The commission emphasized, that this conclusion was only an
impression from its investigations and not the result of a systematic
poll of computer scientists.

  "Although the act was reckless and impetuous, it appears to have
been an uncharacteristic act for Morris" because of his past efforts
at Harvard and elsewhere to improve computer security, the commission
report said.

  Of the need for increased security on research computers, the
commission wrote, "A community of scholars should not have to build
walls as high as the sky to protect a reasonable expectation of
privacy, particularly when such walls will equally impede the free
flow of information."

  The trust between scholars has yielded benefits to computer science
and to the world at large, the commission report pointed out.

  "Violations of that trust cannot be condoned.  Even if there are
unintended side benefits, which is arguable, there is a greater loss
to the community as a whole."

  The commission did not suggest any specific changes in the policies
of the Cornell Department of Computer Science and noted that policies
against computer abuse are in place for centralized computer
facilities.  However, the commission urged the appointment of a
committee to develop a university- wide policy on computer abuse that
would recognize the pervasive use of computers distributed throughout
the campus.

  The commission also noted the "ambivalent attitude towards reporting
UNIX security flaws" among universities and commercial vendors.  While
some computer users advocate reporting flaws, others worry that such
information might highlight the vulnerability of the system.

  "Morris explored UNIX security amid this atmosphere of uncertainty,
where there were no clear ground rules and where his peers and mentors
gave no clear guidance," the report said.

  "It is hard to fault him for not reporting flaws that he discovered.
>From his viewpoint, that may have been the most responsible course of
action, and one that was supported by his colleagues."

  The commission report also included a brief account of the worm's
course through Internet.  After its release shortly after 7:26 p.m. on
Nov 2, the worm spread to computers at the Massachusetts Institute of
Technology, the Rand Corporation, the University of California at
Berkeley and others, the commission report said.

  The worm consisted of two parts--a short "probe" and a much larger
"corpus."  The probe would attempt to penetrate a computer, and if
successful, send for the corpus.

  The program had four main methods of attack and several methods of
defense to avoid discovery and elimination.  The attack methods
exploited various flaws and features int he UNIX operating systems of
the target computers.  The worm also attempted entry by "guessing" at
passwords by such techniques as exploiting computer users'
predilections for using common words as passwords.

  The study's authors acknowledged computer scientists at the
University of California at Berkeley for providing a "decompiled"
version of the worm and other technical information.  The Cornell
commission also drew on analyses of the worm by Eugene H. Spafford of
Purdue University and Donn Seeley of the University of Utah.

 ------- End of Forwarded Message

------------------------------

End of VIRUS-L Digest
*********************


VIRUS-L Digest            Wednesday, 12 Apr 1989        Volume 2 : Issue 86

Today's Topics:
(c) Brain killers wanted (PC)
Worm reports for BITNET subscribers
nVIR removal (Mac)
Debrain.. (PC)
virus conference
Why write a virus?

---------------------------------------------------------------------------

Date:         Tue, 11 Apr 89 03:05:49 ECT
From:         Ken Hoover <[e-mail]>
Subject:      (c) Brain killers wanted (PC)

  We've been fighting what appears to be a winning battle against the
(c) Brain variant of the Brain virus here at SUNY-Binghamton for the
last couple of weeks.  Having just finished removing the little
buggers from a few of our disks (marked as suspicious because the
write protect tabs we put on them were gone), I am wondering if any of
the boot sector-restoring programs for the PC would be effective
against this virus.  Is wiping the boot sector effective against this
one?

Ken Hoover
UG Consultant, SUNY-Binghamton Computer Center.
Binghamton, NY, USA.

------------------------------

Date:       Tue, 11 Apr 89 09:05:50 BST
From:       David.J.Ferbrache <[e-mail]>
Subject:    Worm reports for BITNET subscribers

The full set of reports on the Internet worm is available from the
Heriot-Watt info-server at <[e-mail]>. Please only
request if you are a bitnet site in the US or Europe who can not
obtain these reports from other mail based archive servers.

1. A tour of the worm, Donn Seeley, Dept of computer science, University of
   Utah. Nroff me macros
   Topic: unix.utah

2. A report on the internet worm, Bob Page, Dept of computer science,
   University of Lowell.
   Plaintext
   Topic: unix.page

3. The internet worm program: an analysis, Eugene Spafford, Dept of
   computer science, Purdue University. Postscript
   Topic: unix.worm

4. With Microscope and Tweezers, an analysis of the internet virus of
   Nov 1988, Mark Eichin and Jon Rochlis, MIT. Postscript
   Topic: unix.mit

also worth reading

5. NSF Internet computer virus update, copyright CCNEWS
   Topic: unix.nsfupdate

To retrieve send mail to <[e-mail]> of the form:

request: virus
topic: unix.mit

where the topic is given above, one or more topic lines can be included.

The server also holds a reasonably complete set of anti-viral software
and backissues of virus-l. The materials include all programs and
utilities available from RPICICGE, LEHIIBM1, SCFVM, INFO-MAC and
INFO-APPLE archives.

For a general index send:

request: index
topic: index

for materials specific to anti-viral measures send:

request: virus
topic: index

Cheers.

Dave Ferbrache                         Personal mail to:
Dept of computer science               Internet <[e-mail]>
Heriot-Watt University                 Janet    <[e-mail]>
79 Grassmarket                         UUCP     ..!mcvax!hwcs!davidf
Edinburgh,UK. EH1 2HJ                  Tel      (UK) 031-225-6465 ext 553

------------------------------

Date:         Tue, 11 Apr 89 04:35:21 EDT
From:         David Wind <[e-mail]>
Subject:      nVIR removal (Mac)

     Is there a Macintosh application available on Bitnet that will
remove the nVIR virus from a Macintosh application without destroying
the infected application? (If so, how could I get a copy of it?)
                                                          D. WIND
                                                          347RNSD@CMUVM
Acknowledge-To: <347RNSD@CMUVM>

------------------------------

Date:         Tue, 11 Apr 1989 11:00:57 EDT
From:         James Paterson <[e-mail]>
Subject:      Debrain.. (PC)

Hello...University of Guelph just discovered brain in one of our micro
clusters, and I was looking for Debrain, or any other anti-viral
programmes.  I seem to recall that there was some stored away on an
.EDU node, but I am not sure.  Can anyone tell me where I could obtain
a copy of debrain, etc??

Thanks in Advance..

James Paterson
Student Consultant, University of Guelph
NetNorth: ACDJAMES@UOGUELPH
                        -------------------------------
Old soldiers never die.  Young ones do.

------------------------------

Date:    Tue, 4 Apr 89 21:54 CST
From:    "Paul Duckenfield (x5107)" <[e-mail]>
Subject: virus conference

I would like to get some information on the upcoming virus conference,
or if I have missed it, where I can pick up information from the
conference.

Paul Duckenfield
[e-mail]

[Ed. Give the Computer Security Institute a call at (508)-393-2600.]

------------------------------

Date:     Tue, 11 Apr 89 13:34:06 -0900
From:     Chris Hartman                    <[e-mail]>
Subject:  Why write a virus?

        I know this was discussed about a month ago, but it was only
touched upon very briefly.  I would like to know everybody's opinion
on what reasons people have for writing and releasing viruses. I am
expecially concerned with those that are not for revenge or other
personal reasons.  Please send your replies to FSCMH1@ALASKA and in a
week or so I will post the results on the list.
        T.I.A.
            -Chris Hartman

------------------------------

End of VIRUS-L Digest
*********************

VIRUS-L Digest            Wednesday, 12 Apr 1989        Volume 2 : Issue 87

Today's Topics:
Re: VIRUS-L Guidelines???
Availability of FluShot+ (PC)
need source for ibm/mac anti-viral programs
Cohen paper in C&S

---------------------------------------------------------------------------

Date:    Wed, 12 Apr 89 12:51:03 EDT
From:    Chris Siebenmann <[e-mail]>
Subject: Re: VIRUS-L Guidelines???

 Fred Hartmann asked in V2 #84 about redistribution to other sites of
VIRUS-L, and worried about people using information appearing here to
make better viruses/worms/whatever. I'd like to point out that VIRUS-L
is already pretty wide-spread -- I'm reading it on Usenet, for example
(through a set of UofToronto-wide newsgroups which are gatewayed with
various mailing lists).

 Unless you know for sure otherwise, it's wise to assume any message
sent to a public mailing list will be rebroadcast to the world and
thus not put anything in such messages you don't mind the world
seeing. It's also a maxim of security that the bad guys know all of
this information already, but the good guys don't (bad guys have lots
of communication methods).

[people interested in a long discussion on the above maxim should
check out back issues of RISKS DIGEST.]
- ---
"I shall clasp my hands together and bow to the corners of the world."
                Number Ten Ox, "Bridge of Birds"
Internet: [e-mail]         BITNET: [e-mail]

------------------------------

Date:    Wed, 12 Apr 89 15:00 EDT
From:    Roman Olynyk - Information Services <[e-mail]>
Subject: Availability of FluShot+ (PC)

I notice that the latest issue of PC Magazine rates FluShot+ quite
well (one of two Editor's Choices).  Does anyone know of either an
Internet or BITNET source for this shareware program?  I know it's
available on some BBSs and CompuServ, but I'd prefer to download it at
something faster than the 1200 baud speed I'm stuck with at home.  By
the way, I nosed around the MSDOS.Trojan-Pro files on SIMTEL20, and
was surprised not to have found it there.  Any ideas?

------------------------------

Date:    Wed, 12 Apr 89 13:21 MDT
From:    "Kurt Miles, VAX Consultant" <[e-mail]>
Subject: need source for ibm/mac anti-viral programs

I am as consultant for Utah state university, and we have several open
labs.  We have a recurring problem with virii cropping up, and I was
qwondering if there was a good (and hopefully free) archive or
repositiory of anti-viral software for those systems that is current
and available through bitnet/internet?

I have the index from lehiibm1 and from scfvm.  are ther any other good
sources?

Thanks a million.

KMILES@USU   (bitnet)

------------------------------

Date:    Wed, 12 Apr 89 15:34:00 EDT
From:    [e-mail] (Kenneth R. van Wyk)
Subject: Cohen paper in C&S

The latest issue of Computers & Security has an interesting article by
Dr. Cohen entitled "Practical Defenses Against Computer Viruses".  In
the paper, he (Dr. Cohen) presents various techniques for notifying
the user of any change in executable files before they get executed.
At least one of his techniques utilizes his cryptographic checksum
method of digital signatures.  (This method was described in an
earlier C&S article.)  Of particular interest to me are the benchmark
times which he mentions for the various levels of his protection
scheme (he discusses prototypes on various different machines).  The
times seem to be exceptionally fast, and certainly acceptable.

I'd be very interested to see an implementation (Unix and/or MS-DOS)
of his S3 level protection, if anyone has done one (or is working on
one).

Ken

------------------------------

End of VIRUS-L Digest
*********************
VIRUS-L Digest             Thursday, 13 Apr 1989        Volume 2 : Issue 88

Today's Topics:
General question....
Re: hard disk write protection
antiviral archives (Mac)
Re: nVIR Removal (Mac)
Mac software repository
Availability of FLU_SHOT+ on Simtel20.Army.Mil (PC)
Hard disk write protection
More on the Alameda Virus (PC)

---------------------------------------------------------------------------

Date:         Wed, 12 Apr 1989 19:57 EST
From:         Bruce Ide <[e-mail]>
Subject:      General question....

If the virus needs to access the disk to spread why not have the
computer manufactorers modify their HARDWARE slightly so that any disk
writes are questioned? It would get irritating to users, true, but if
you don't specify save and a write occurs, I expect it would be
questioned and perhaps the user would even have enough sense to deny
access... This idea as I have it now is very rough... With some
polishing, it might be ok, but you've probably had ones like it
before, and I could probably read all about it if I felt like digging
through several years worth of archives :)

------------------------------

Date:    Wed, 12 Apr 89 23:06:56 EDT
From:    [e-mail] (Bill Van Emburg)
Subject: Re: hard disk write protection

> If you do figgure out how to do this, you could probably set up a
> toggle switch or key thing to alllow you to write to your disk
> when it's switched one way and keep write protection on when it's
> switched the other. If you want to keep users out, set it up with the
> key. If it's to keep viri out, set it up with the switch. It'll take

The problem with this idea is that many programs need to write
temporary files to disk.  Often, the user is completely unaware that
this is happening.  If you set a hardware write protect, you may find
that your favorite utility doesn't work.  While this *could* serve a
useful purpose in some settings, I don't feel that it could be a
widespread solution.

                        -Bill Van Emburg
                        ([e-mail])
                        {...}!rutgers!aramis.rutgers.edu!vanembur

------------------------------

Date:    Wed, 12 Apr 89 23:13:28 CDT
From:    "David Richardson, UT-Arlington" <[e-mail]>
Subject: antiviral archives (Mac)

In response to the question about antiviral archives,
SUMEX-AIM.STANFORD.EDU has a HUGE Mac archive, which is anonymously
ftp-able.  It has all the anti-viral software, including
disinfectant.

- -David Richardson,                    The University of Texas at Arlington
Bitnet: b645zax@utarlg            Internet:  [e-mail]
UUCP:     ...!{ames,sun,texbell, <backbone>}!utarlg.arl.utexas.edu!b645zax
SPAN:     ...::UTSPAN::UTADNX::UTARLG::b645ZAX      US Mail: PO Box 192053
PhoNet: [phone] (FREE from Dallas, TX)    Arlington, TX 76019-2053

------------------------------

Date:    Thu, 13 Apr 89 02:10 EDT
From:    "Mark H. Anbinder" <[e-mail]>
Subject: Re: nVIR Removal (Mac)

The nVIR virus (all currently-known strains, including those with
different names) can be removed with the Disinfectant program, written
by John Norstad and assisted by a group of programmers who
collaborated via the Internet.  Disinfectant 1.0 is available from
various servers, or I could e-mail you a copy.  Disinfectant 1.1,
which includes mostly bug fixes, is expected to be released on Monday
17 April.  If you wish to use it over a TOPS network, wait for 1.1.

Mark H. Anbinder
Department of Media Services
Cornell University

------------------------------

Date:         Thu, 13 Apr 89 08:37:07 EST
From:         Joe Simpson <[e-mail]>
Subject:      Mac software repository

Joe McMahan maintains a superior repository of Mac software on
LISTSERV at SCFVM

The repository includes
A Hypercard documentation stack
VACCINE  a very nice protection cDev
GATEKEEPER  another very nice protection cDev for programmers
VirusRX  Apple's disgnostic
Interferon another very nice diagnostic.

------------------------------

Date:    Thu, 13 Apr 89 07:53:08 MDT
From:    Chris McDonald  ASQNC-TWS-R 678-4176 <[e-mail]>
Subject: Availability of FLU_SHOT+ on Simtel20.Army.Mil (PC)

FLU_SHOT+, Version 1.5, has been available on simtel20.army.mil for
over one month.  It can be found in the directory
pd1:<msdos.trojan-pro>.  The copy posted was obtained directly from
the author, Ross Greenberg.

[Ed. Thanks for the speedy work!]

------------------------------

Date:    Thu, 13 Apr 89 10:24:51 CDT
From:    [e-mail]
Subject: Hard disk write protection

>Could some hardware hacker upload instructions on disabling the write
>capability of an XT or AT style hard disk?

>[Ed. The problem with that is that the entire hard disk would be
>read-only (which could be useful for some applications).

>It'll take a bit of soldering, and a few thirty nine cent swtiches
>from radio shack.

Communications is obviously more difficult than just being able to send
messages!  I have developed a hardware write-protect swithc as mention.
I received a patent on it almost a year ago.

Let me make a few points.

1. It is 100% effective against modification of protected files.
2. You DO NOT have to protect the entire hard disk.
3. It requires more than a $.39 switch, unless you don't mind cooking
your disk electronics.
4. It has been available for over two years.
5. It CAN NOT be disabled by ANY software!

Dennis Director,  [e-mail]

------------------------------

Date:    Thu, 13-Apr-89 11:01:35 PDT
From:    portal!cup.portal.com![e-mail]
Subject: More on the Alameda Virus (PC)

In digest 2.74, Y. Radai brought up some inconsistencies he had found
between descriptions of the Yale virus and John McAfee's description
of the Alameda virus.  He asks:

>   So Gary, since you obviously are able to contact McAfee, would you
> mind asking him (1) to clarify the inconsistency in the dates, (2) to
> give us all available details on the Alameda-Merritt virus, and (3) to
> provide all the evidence he has for concluding that Alameda = Yale.

Here is John's response:

> 04/04/89 00:25:26
> From: JOHN MCAFEE
>
> Gary, thanks again for serving as courier for these messages.  In response
> to the questions:  The Alameda was first discovered in Spring 1987 at
> Merritt College.  It popped up again at Alameda College, where it received
> large publicity, in February, 1988.  It is identical to a virus given to
> me by Loren Keim in October of 1988, and Loren called the virus the Yale
> virus - hence my certainty.  To remove any doubts, however, I am placing
> my disassembly of the Alameda virus in the MS-DOS SIG for you to forward
> along with my message.  If I have been incorrect in my analysis, then I
> apologize to the august body of East coast researchers.  I think, however,
> that the disassembly should match the Yale perfectly.  Thank you for your
> time.  (The disassembly is called - ALAMEDA.ASM).

The complete virus disassembly has been sent to Y. Radai via e-mail.  Here
is the comment block from the front of John's disassembly:

; This virus is of the "FLOPPY ONLY" variety.
; It replicates to the boot sector of a floppy disk and when it gains control
; it will move itself to upper memory.  It redirects the keyboard
; interrupt (INT 09H) to look for ALT-CTRL-DEL sequences at which time
; it will attempt to infect any floppy it finds in drive A:.
; It keeps the real boot sector at track 39, sector 8, head 0
; It does not map this sector bad in the fat (unlike the Pakistani Brain)
; and should that area be used by a file, the virus
; will die.  It also contains no anti detection mechanisms as does the
; BRAIN virus.  It apparently uses head 0, sector 8 and not head 1
; sector 9 because this is common to all floppy formats both single
; sided and double sided.  It does not contain any malevolent TROJAN
; HORSE code.  It does appear to contain a count of how many times it
; has infected other diskettes although this is harmless and the count
; is never accessed.
;
; Things to note about this virus:
; It can not only live through an ALT-CTRL-DEL reboot command, but this
; is its primary (only for that matter) means of reproduction to other
; floppy diskettes.  The only way to remove it from an infected system
; is to turn the machine off and reboot an uninfected copy of DOS.
; It is even resident when no floppy is booted but BASIC is loaded
; instead.  Then when ALT-CTRL-DEL is pressed from inside of BASIC,
; it activates and infects the floppy from which the user is
; attempting to boot.
;
; Also note that because of the POP CS command to pass control to
; its self in upper memory, this virus does not work on 80286
; machines (because this is not a valid 80286 instruction).
;
; The Norton utilities can be used to identify infected diskettes by
; looking at the boot sector and the DOS SYS utility can be used to
; remove it (unlike the Brain).

Gary Tom
Tandem Computers, Inc.
Cupertino, CA

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest              Friday, 14 Apr 1989         Volume 2 : Issue 89

Today's Topics:
RE: Having hardware check writes to disk.
re: More on the Alameda Virus (PC)
Anti-viral archive at SCFVM (Mac)
Re: More on Yale virus (PC)
re: general question

---------------------------------------------------------------------------

Date:     Thu, 13 Apr 89 18:53 EST
From:     Go Reds! <[e-mail]>
Subject:  RE: Having hardware check writes to disk.

     The suggested solution of having hardware question writes to disk
does not seem to be feasible.  I work a lot with VAX Pascal and it is
common for me to write to files a lot in programs.  This would mean I
would have to sit there and ok every write, highly inefficent.  A
better way would be to question writes to the operating system (I
believe FluShot.com does this) since the way to make a virus most
effective seems to me to be by infecting the operating system, thus
changing what the run command does, thus enabling the virus to spread.
Well, that's all I've got to add to this.

Tom Kummer

------------------------------

Date:    14 April 1989, 09:20:02 EDT
From:    David M. Chess         <[e-mail]>
Subject: re: More on the Alameda Virus (PC)

That does sound very much like the sample that I got from Yale, which
I'm pretty sure is the same one that Loren got from Yale, and so is
presumably the one that J.M. says is identical to the Alameda/Merrit.
(Whew!)  Presumably the "first free sector" in the article was a case
of slight oversimplification for the sake of making it fit into the
table?                                        DC

------------------------------

Date:         Fri, 14 Apr 89 10:01:00 EDT
From:         Joe McMahon <[e-mail]>
Subject:      Anti-viral archive at SCFVM (Mac)

Hello all. We are going to be reorganizing the anti-virals archive
here at SCFVM in the next week or so, to coincide with the rerelease
of my anti-viral doc stack (version 2.0). I will be posting details
when we've finalized them; I will probably be removing anything which
is no longer supported (such as Interferon - since Bob Woodhead is
concentrating on Virex now), or which has been outmoded.

 --- Joe M.

------------------------------

Date:         Fri, 14 Apr 89 13:26:12 EDT
From:         "Conrad Jacoby (DC)" <[e-mail]>
Subject:      Re: More on Yale virus (PC)

HI there!!

    As one of the original discoverers of the Yale virus this summer,
I wish to make one comment in regards to a recent posting (Virus-L, v2
#88, last posting) that claimed that Almeda virus=Yale.  In whoever's
posting of thier summary, there was a statement that this virus did
not work in 80286 machines because of different memory addresses and
the like.  If this is indeed true, than there is no way that the
Almeda virus and the Yale virus can be the same creatures.  All our
public domain machines are IBM ATs, and the virus was transmitted
quite successfully through any number of them.  Indeed, I have no
experience with the virus except on '286 machines.

    Could someone more knowledgeable about viruses and internal
differences between 8088 and 80286 machines comment on this?

- -----------------------------------------------------------------------
Conrad J. Jacoby                       P.O. Box 3805 Yale Station
Yale University                        New Haven, CT 06520
Sterling Memorial Library              [phone]
"Generalist at Large"                  [e-mail]
                                             @YaleVM.YCC.Yale.Edu
- -----------------------------------------------------------------------

------------------------------

Date:         Fri, 14 Apr 89 14:07:35 EST
From:         Neil Goldman <[e-mail]>
Subject:      re: general question

Bruce Ide suggests that the user could confirm all disk writes.

Three immediate problems.

1. For every disk write, it would be a pain in the #&*%.  Besides,
users would get very complacent and OK everything without analyzing
what is, should, and should not be written just before the little red
light goes on.

2. Inexperienced users would not understand when they should confirm a
write to begin with.

3. A virus could:
   a) simulate a "save" so the hardware thinks it is OK
   b) wait for a legitimate save to occur and propagate during that
      operation.

I'm sure there are many other arguments against this methodology as
well.  But, Bruce, the more we work on the problem, the closer we get
to a (if this is possible) a solution.  So keep those ideas coming!

***************************************************************
*Neil A. Goldman                        [e-mail]*
*                                                             *
*   Replies, Concerns, Disagreements, and Flames expected     *
*    Mastercard, Visa, and American Express not accepted      *
***************************************************************
Acknowledge-To: <NG44SPEL@MIAMIU>

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest              Monday, 17 Apr 1989         Volume 2 : Issue 90

Today's Topics:
I need assistance (PC)
Flu_Shot+ availability (PC)
Ignorance is not the answer
Legal aspects of viruses

---------------------------------------------------------------------------

Date:     Fri, 14 Apr 89 17:04 EST
From:     <[e-mail]>
Subject:  I need assistance (PC)

Over the course of the past week, I have had three of my 3.5"
diskettes "blow up". In all cases I have received error messages when
trying either to run .EXE files or trying to do a directory. The first
diskette had a scrambled FAT, and boot sector. The same held true with
the second, however, there was the added discovery that all sectors on
that disk were bad. The third diskette is completely unaccessible,
either by trying to execute files or do directories. I have not, at
this point tried to discover the extent and exact nature of the damage
to this diskette. I am nowhere ready to cry virus, but in all honesty,
I wouldn't know a virus if it kicked me in the shin. At this point I
am unsure as to how to go about eliminating other types of operator
and/or hardware problems. Any help that the readers of this group can
offer would be greatly appreciated. I don't want to run around like a
chicken with my head chopped off, and really need to kow how to go
about eliminating or confirming the more ordinary problems that crop
up. Thanks in advance.

Steve Grigg
STU_SMGR@JMUVAX1

------------------------------

Date: Fri Apr 14 23:14:34 1989
From: utoday![e-mail]
Subject: Flu_Shot+ availability (PC)

Just as a note for Virus-L: the current version of FLU_SHOT+ is 1.52.
It is always available for free on my BBS at (212)-889-6438
(2400/1200/ N/8/1/24hr).  I will forward a copy over to SIMTEL-20 on
my next distributor fufillment cycle (middle of week of April-16)

Ross M. Greenberg, Author FLU_SHOT+

------------------------------

Date: Fri, 14 Apr 89 22:39 CDT
From: [e-mail]
Subject: Ignorance is not the answer

> From:     Chris Siebenmann <[e-mail]>
> Subject: Re: VIRUS-L Guidelines???
>
>  Unless you know for sure otherwise, it's wise to assume any message
> sent to a public mailing list will be rebroadcast to the world and
> thus not put anything in such messages you don't mind the world
> seeing. It's also a maxim of security that the bad guys know all of
> this information already, but the good guys don't (bad guys have lots
> of communication methods.

My feelings exactly.  An adage that's been going around the industry
for some time now is "Ignorance is no substitute for security."

Malcolm Petcher
Texas Instruments, Inc.

------------------------------

Date:     Sun, 16 Apr 89 18:19 CDT
From:     <[e-mail]>
Subject:  Legal aspects of viruses

I need any information on the punishment, present laws, and pending
laws that deal with implementing computer viruses for an english paper
any information would be greatly appreciated
                                James Ray
                                Auburn University

------------------------------

End of VIRUS-L Digest
*********************

VIRUS-L Digest              Monday, 17 Apr 1989         Volume 2 : Issue 91

Today's Topics:
Fred Cohen's papers...
re: Yale virus = Alameda virus (PC)
Disinfectant 1.1 (Mac)
Re: More on Yale virus (PC)
Information wanted on "Stoned" virus (PC)
re: computers & media piece on virus-l

---------------------------------------------------------------------------

Date:    Sat, 15 Apr 89 13:00:35 EST
From:    (David M. Gursky) [e-mail]
Subject: Fred Cohen's papers...

The question came up recently about Fred Cohen's papers and how to
obtain them.  The address in Pittsburgh is correct (Fred Cohen, c/o P.
O. Box 90069, Pittsburgh, Pennsulvania 15224).  The cost (for those
who have misplaced the message from December) is $20 for Fred's
thesis, and $20 for the assorted articles.

------------------------------

Date:         Sat, 15 Apr 89 15:44:28 EDT
From:         Naama Zahavi-Ely <[e-mail]>
Subject:      re: Yale virus = Alameda virus (PC)

The "Yale" virus indeed does not work on 20286 machines, in the sense
that if one tries booting a 20286 machine with an infected disk the
machine will hang.  In effect, the ONLY active part of the machine at
that point is the virus -- if you then do Ctrl-Alt-Del with a
non-write-protected disk in the A drive, that diskette will get
infected.  On a PC, if you boot from an infected disk, the virus is
loaded into memory and will infect other disks upon soft-boot, but
otherwise it is completely transparent and is not likely at all to be
discovered.  The only reason we caught it at Yale is that all our
machines are 20286 machines, and we were suddenly faced with machines
not booting properly.  The person who we suspect brought the virus to
Yale (unknowingly) insisted at the time that his disk, which was not
working properly at our public facilities, was working perfectly at
his home and elsewhere.  He was using ordinary PCs at these places.  I
have also verified this effect myself using an authentic copy of the
"Yale" virus.

I personaly am convinced that the Yale virus is the same as the
Alameda virus.

Thanks,

+ -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- +
|  Naama Zahavi-Ely                                                    |
|  Project ELI                           E-MAIL [e-mail]   |
|  Yale Computer Center                                                |
|  175 Whitney Ave                                                     |
|  New Haven, CT 06520                                                 |
|  [phone] ext. 341                                             |
+ -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- +

------------------------------

Date:        Mon, 17 Apr 89 08:44:28 EDT
From:        [e-mail]
Subject:     Disinfectant 1.1 (Mac)

Disinfectant Version 1.1 Announcement & Press Release.

April 16, 1989.

Disinfectant 1.1 is a new release of a program to detect and remove
Macintosh viruses.

Version 1.1 recognizes the new MEV# virus that was discovered in
Belgium a few weeks ago.  Version 1.1 also fixes a few bugs and adds
several new features.  For a detailed list of all the changes see the
new section titled "Version History" in the online document.

We recommend that all Disinfectant users obtain a copy of the new
version.

With version 1.1 we are also now distributing a formatted version of
the document, with screen shots and other pictures, a table of
contents, etc.  See the online document for details on how to obtain a
copy.

Version 1.1 has been posted to CompuServe, AppleLink,
comp.binaries.mac, and info-mac.  It should be available from those
sources soon, as well as from many other bulletin boards, commercial
online services, user groups, and Internet archive sites.

Features:

- - Detects and repairs files infected by Scores, nVIR A, nVIR B, Hpat,
  AIDS, MEV#, INIT 29, ANTI, and MacMag.  These are all of the currently
  known Macintosh viruses.
- - Scans volumes (entire disks) in either virus check mode or virus
  repair mode.
- - Option to scan a single folder or a single file.
- - Option to "automatically" scan a sequence of floppies.
- - Option to scan all mounted volumes.
- - Can scan both MFS and HFS volumes.
- - Dynamic display of the current folder name, file name, and a thermometer
  indicating the progress of a scan.
- - All scans can be canceled at any time.
- - Scans produce detailed reports in a scrolling field.  Reports can be
  saved as text files and printed with an editor or word processor.
- - Carefully designed human interface that closely follows Apple's
  guidelines.  All operations are initiated and controlled by 8 simple
  standard push buttons.
- - Uses an advanced detection and repair algorithm that can handle partial
  infections, multiple infections, and other anomalies.
- - Careful error checking.  E.g., properly detects and reports damaged and
  busy files, out of memory conditions, disk full conditions on attempts
  to save files, insufficient privileges on server volumes, and so on.
- - Works on any Mac with at least 512K of memory running System 3.2
  or later with HFS.
- - Can be used on single floppy drive Macs with no floppy shuffling.
- - 11,000 word online document describing Disinfectant, viruses in
  general, the Mac viruses in particular, recommendations for "safe"
  computing, Vaccine, and other virus fighting tools.  We tried to
  include everything in the document that the average Mac user needs to
  know about viruses.

I wrote Disinfectant with the help of an international group
of Mac virus experts, programmers and enthusiasts: Wade Blomgren,
Chris Borton, Bob Hablutzel, Tim Krauskopf, Joel Levin, Robert Lentz,
Bill Lipa, Albert Lunde, James Macak, Lance Nakata, Leonard Rosenthol,
Art Schumer, Dan Schwendener, Stephan Somogyi, David Spector, and
Werner Uhrig.

These people helped design and debug the program, edit the document,
locate copies of the viruses for testing, and analyze the viruses.  I
wrote all the code, but I could not have written the program without
their help.

Disinfectant is an example of a new kind of cooperative software
development over the internet. It was developed over a period of three
and one half months starting on December 1, 1988. During this period I
sent out nine development releases and nine Beta releases to the
working group, and we exchanged several hundred notes. The result is a
program that is much better than any one of us could have produced
individually.

We are offering this program free of charge as a public service.  We
hope that the Mac community finds it useful.

John Norstad
Academic Computing and Network Services
Northwestern University

Bitnet:      jln@nuacc
Internet:    [e-mail]
AppleLink:   a0173
CompuServe:  76666,573

------------------------------

Date:         17 April 1989, 09:22:27 EDT
From:         David M. Chess  <[e-mail]>
Subject:      Re: More on Yale virus (PC)

The Yale virus (at least the one I have!) does contain a "POP CS".
Mr. McAfee is oversimplifying slightly again; "POP CS" is a perfectly
valid instruction on '286 machines in real mode (which is how DOS
runs).  It's just not a valid instruction in protect mode (which is
how OS/2 runs, for instance).  I'm not quite clear on when in the boot
cycle an OS/2 machine enters protect mode; in any case, the virus does
contain "POP CS", but that's consistent with your having seen it on
ATs.

DC

------------------------------

Date:    Mon, 17 Apr 89 13:35 EDT
From:    [e-mail]
Subject: Information wanted on "Stoned" virus (PC)

Has anyone encountered a virus that writes the message "Your PC is now
Stoned! LEGALISE MARIJUANA!" in the boot sector of an infected floppy?
Any information would be appreciated.

Tom Sheriff
Microcomputer Support Group
University of North Carolina at Greensboro
[e-mail]

------------------------------

Date:         Mon, 17 Apr 89 15:15:16 EST
From:         Neil Goldman <[e-mail]>
Subject:      re: computers & media piece on virus-l

Dear Dimitri,

Hi.  I just read your posting.  It is very insightful and interesting.
It is unfortunate that there is no practical way for those of us who
'understand' the issues to serve as editors-in-chiefs for all
publications of this type.

This serves as another facet of problems with the media.  Presumably,
the author of the article has some expertise.  But even if he doesn't,
the reader will still place (undue) reliance upon his statements.

For some problems, unfortunately, there is no easy solution.

- - Neil

***************************************************************
*Neil A. Goldman                        [e-mail]*
*                                                             *
*   Replies, Concerns, Disagreements, and Flames expected     *
*    Mastercard, Visa, and American Express not accepted      *
***************************************************************
Acknowledge-To: <NG44SPEL@MIAMIU>

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest             Tuesday, 18 Apr 1989         Volume 2 : Issue 92

Today's Topics:
hardware write locks
Review of THE COMPUTER VIRUS CRISIS
Amiga Floppy Write Protection
possible new VIRUS (PC)
The Laplink III Virus (PC)

---------------------------------------------------------------------------

Date:    Mon, 17 Apr 89 15:41:50 CDT
From:    "Len Levine" <[e-mail]>
Subject: hardware write locks

>From:         Bruce Ide <[e-mail]>
>
>If the virus needs to access the disk to spread why not have the
>computer manufactorers modify their HARDWARE slightly so that any disk
>writes are questioned? It would get irritating to users, true, but if
>you don't specify save and a write occurs, I expect it would be
>questioned and perhaps the user would even have enough sense to deny
>access... This idea as I have it now is very rough... With some
>polishing, it might be ok, but you've probably had ones like it
>before, and I could probably read all about it if I felt like digging
>through several years worth of archives :)

There are such products commercially available.  They permit tracks on
the hard disk to be markded as read-only, track by track.  Because of
the use of FAT, however, this requires that entire logical devices be
made read-only or read-write.  I have one such commercial device and
it works just fine.

+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
| Leonard P. Levine               e-mail [e-mail] |
| Professor, Computer Science             Office [phone] |
| University of Wisconsin-Milwaukee       Home   [phone] |
| Milwaukee, WI 53201 U.S.A.              Modem  [phone] |
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +

------------------------------

Date:    Mon, 17 Apr 89 17:11:46 EST
From:    Mark Paulk <[e-mail]>
Subject: Review of THE COMPUTER VIRUS CRISIS

The following review was done for IEEE Computer and may be of some
interest to the VIRUS-L readers. I have added some of my notes which
summarize the errors and misleading statements I saw in the book after
the review. If anyone notes any factual errors in the review, please
e-mail me, and I'll try to correct them before publication.

- - ------------------

THE COMPUTER VIRUS CRISIS
   Philip Fites, Peter Johnston, and Martin Kratz
   (Van Nostrand Reinhold, New York, NY, 1989, 171 pp.)

The objective of THE COMPUTER VIRUS CRISIS is to inform personal
computer users about the virus phenomenon. It is written for people
without in-depth technical backgrounds. THE COMPUTER VIRUS CRISIS
defines viruses, worms, and Trojan horses, and the types of thing that
viruses have and can to do computers. Famous viruses such as the
MacMag, nVir, and Brain viruses are described. High risk practices are
discussed, and "safe hex" practices recommended. Software for
preventing, detecting, and recovering from viruses is discussed, and
anti-viral software packages are listed, along with contacts for
obtaining the software.

I looked forward to reviewing this book. Computer viruses are a hot
topic.  Viruses have allegedly been written by 14-year-olds (the
HyperAvenger virus).  Approximately 350,000 Mac uses were reportedly
hit by the MacMag virus.  Unfortunately THE COMPUTER VIRUS CRISIS is
not the book that I want.

THE COMPUTER VIRUS CRISIS is aimed at a non-technical audience.
Schoolteachers, accountants, or managers may find it fascinating, but
for software professionals the technical content is minimal. As such
its value to a professional audience is small. The list of antiviral
software packages may be of value, but such a list quickly becomes
dated. One concern is the statement in some package descriptions that
"no indication is given in the documentation as to whether this is
freeware, shareware, or a commercial product." I have to feel that the
book was rather hastily put together if the status of the antiviral
packages is not available.

In reviewing the technical content of the book, I counted 18
statements that I considered misleading or erroneous. These errors
ranged from the fairly trivial to what I consider serious mistakes.
For a trivial example, Fred Cohen being credited as having coined the
term "virus." Len Adleman is generally credited with having coined the
term; Dr. Cohen is credited with doing the first serious research in
computer viruses.

A more serious example is the suggestion that you can be exposed to a
virus if you are on a net even if you practice "safe hex." While you
may be exposed to a worm program if your computer is networked,
viruses are not related to computer networks at all. A virus is a
program that reproduces by modifying existing programs and files. A
worm is a program that replicates itself through a network. The
distinction can blur at times, and the term virus has been misused in
the media so much that its technical meaning is seriously compromised
(the Internet worm was originally reported as the Internet virus).

Fites, Johnston, and Kratz define virus correctly in THE COMPUTER
VIRUS CRISIS, even pointing out that viruses need not be malicious (a
point frequently overlooked in today's turmoil). However, they state
that worms alter data and code whenever they can get access. Neither
viruses nor worms are inherently malicious. Shoch and Hupp's original
work with worms at Xerox PARC ("The Worm Programs - Early Experience
with a Distributed Computation," CACM, March, 1982, pp. 172-180) was
aimed at harnessing unused resources. Research in this area has
significant implications for parallel computing.

Fites, Johnston, and Kratz consult on computer security and legal
issues, and this bias leads to some interesting, if questionable,
statements. First, that most viruses spread through various violations
of copyright laws or licenses.  Second, that piracy has been a major
cause of a lot of problems, including buggy programs and vaporware
(the statement is also made that vaporware comes from releasing buggy
versions of program, but the definition in the glossary is correct).
Third, that games are specifically targeted by viruses. There is even
a brief discussion of security problems such as piggybacking
communication lines, traffic analysis, and the salami technique.

While I certainly would not wish to appear to condone software piracy,
viruses are eclectic in their attacks. They are just as happy to
attack a licensed spreadsheet program as a bootlegged game - and the
attack proceeds in the same manner. The only example of a specific
application being attacked that I am aware of is the ERIC and VULT
targeting by the Scores virus (ERIC and VULT were internal proprietary
trade secret developments at EDS that Scores checks for specifically).

THE COMPUTER VIRUS CRISIS reiterates one recommendation, however, that
I agree with wholeheartedly. "Backups are the single most important
action you can take to protect yourself against viral attack. They are
also the lowest cost."  Backups are vital even if you are never
infected by a virus. A disk crash can be much more damaging than a
virus.

In summary, THE COMPUTER VIRUS CRISIS appears to have been written
quickly. It has numerous inconsistencies and errors and is not written
for a technical audience. A non-technical audience, however, would
find the book of some value. A technical audience would find the
ongoing discussion on the VIRUS-L BITNET newsgroup, moderated by
Kenneth van Wyk of Lehigh University, of much more value until a
better book is written.

Mark C. Paulk
Software Engineering Institute

- - ----------------------------------------

Fred Cohen coined the term "virus" (5)

worms alter data and code whenever they can get access (6,155)

350,000 Mac uses were hit by the MacMag virus (9) basis?

exposed to virus if you are on a net even if you practice "safe hex" (11)

mainframes in different configurations even with same OS may not be very
vulnerable to virus (12)

Brain virus variation infecting Mac systems (30)

PLO virus infects Amiga systems (36)

anthropomorphic virus in example acting as worm (47)

virus may spread through e-mail (50)

IBM Christmas card was large high-res graphics picture (50)

viruses can hide in CMOS (60) misleading?

games are specifically targeted by viruses (77)

most viruses spread through various violations of copyright laws or
licenses (79)

virus can infect program during development (81) misleading?

vaporware comes from releasing buggy versions of program (84) def is
right (154)

piracy has been a major cause of a lot of problems, including buggy
programs and vaporware (85)

an original, non-bootable diskette ... there's no system on the
diskette to get infected (88)

some anti-viral packages: no indication is given in the documentation
as to whether this is freeware, shareware, or a commercial product
(143)

many viruses are also worms (155)

------------------------------

Date:     Tue, 18 Apr 89 4:14:57 EDT
From:     Sean Casey <[e-mail]>
Subject:  Amiga Floppy Write Protection

Someone stated a short while back that Amiga floppy disk write
protection could be disabled in software.

This is not true. The floppy disk drive hardware has a hardware write
interlock. There is absolutely positively no way in the universe to
write to an Amiga floppy drive if the disk is write-protected.

An Amiga floppy is 100% protected from attacking viruses if it's write
protected.

This information was posted a while back to the Usenet comp.sys.amiga
newsgroup by at least one Commodore-Amiga technical staff member, and
by Dale Luck, one of the original designers of the Amiga 1000.

Sean Casey

- --
***  Sean Casey                         [e-mail], [e-mail]
***  What, me worry?                    {backbone|rutgers|uunet}!ukma!sean
***  ``A computer network should be considerably faster than a slug.'' -Me

------------------------------

Date:     Tue, 18 Apr 89 10:42:03 PDT
From:     [e-mail] (Rollo D. Rogers)
Subject:  possible new VIRUS (PC)

This is a new one on me. Do you know anything about this possible new
virus?  I have contacted the originator of this E-mail msg and asked
for more details.
- -------

Original-Date:    17 Apr 89 21:04:15 GMT
Original-From:    [e-mail]
Original-Subject: DEN ZUK virus

HELP!!!

I work for a University Department called Computer Competency.  Just
recently we have been starting to be attacked by the DEN ZUK virus.
It seems to render the disk useless after re-booting a few times.  I
am sure that we are not the first place that this virus has hit, so I
will not discuss the details.

What I need is help on how to get rid of the virus.  Any program,
technique, anything would be helpful.  This is rather a timely
problem, so help as soon as possible would be appreciated.

The department has just about conquered Macintosh viruses, it would be
nice if we could stop the IBM viruses before they really get started.

    Thank you for any help.
        Jeff Scott
        Computer Competency Department
        Ball State University

------------------------------

From:    "Len Levine" <[e-mail]>
Subject: The Laplink III Virus (PC)
Date:    Tue, 18 Apr 89 14:21:09 CDT

Quoted without permission.  The April 10 issue of InfoWorld on
Page 11 has a 1/4 page article titled:

               New Laplink Capable of Reproducing
  Viruslike Data-Transfer Programs Self-Replicate on Remote PCs
                       by Mark Brownstein

Hoping to prove that not all computer viruses are bad, a pair of
data-transfer programs that use viruslike, self-replicating code
to reproduce themselves on remote PCs is being prepared for
release later this year.

Laplink III from Traveling Software will be capable of
replicating itself onto another system, according to Mark Eppley,
president of Traveling Software.

The $139.95 software, which is designed to pass data between two
PCs, will be capable of detecting if a target computer does not
have Laplink installed.  If the system detects that the target
computer does not have Laplink, it will install the program and
initiate the data transfers.

[ ... material deleted about speed, shipdate, another system
called Fast Lynx from Rupp Corp. that uses a 7 conductor serial
cable, and phone numbers ... ]

I called Traveling Software at 1-800-343-8080 and asked to speak
to a technical person.  I identified myself as a University
Professor in Computer Science and asked "Does this permit me to
connect my laptop with a desktop PC showing the A> prompt and
have my laptop transfer Laplink III to the desktop."  She said:
(here I raise my hand in affirmation) "Yes it does."  I then
asked if it was necessary to turn either machine on.  She was not
sure.  I then asked to speak to a specialist.

The specialist had a different story.  She said that the
newspaper article had some errors.  She said that it was
necessary to run Laptop III on the laptop and to execute some
mode commands on the desktop and (as I remember it) a copy
command.  She said that the advantage of the Laptop software was
that it was not necessary to have a disk with you that fit the
desktop in order to mount the software on the pair.  I agreed
with the technique and with the advantage of using such a system.

We may rest easy.  This new software does not sneak down the wire
and infect your office machine.  For a moment there I was in
grave doubt.

+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
| Leonard P. Levine               e-mail [e-mail] |
| Professor, Computer Science             Office [phone] |
| University of Wisconsin-Milwaukee       Home   [phone] |
| Milwaukee, WI 53201 U.S.A.              Modem  [phone] |
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest            Wednesday, 19 Apr 1989        Volume 2 : Issue 93

Today's Topics:
Administrative request to students
Flushot+ 1.52 (PC)
RE: Review of THE COMPUTER VIRUS CRISIS
Virus-handling Policies or Procedures at Mainframe Sites?
CheckSum Methods of Virus Detection (PC)

---------------------------------------------------------------------------

Date:     Tue, 18 Apr 89 16:50:45 EDT
From:     [e-mail] (Kenneth R. van Wyk)
Subject:  Administrative request to students

With the end of the semester approaching (already?!), I'd like to ask
all student subscribers who don't plan to be around over the summer to
unsubscribe from VIRUS-L before they leave for summer break.  It will
save me a great deal of effort.

To unsubscribe, send mail to [e-mail] (*NOT* to
VIRUS-L) saying "SIGNOFF VIRUS-L".  That's all there is to it.

Thanks in advance,

Ken

------------------------------

Date:         Tue, 18 Apr 89 11:25:50 CDT
From:         James Ford <[e-mail]>
Subject:      Flushot+ 1.52 (PC)

You say that the current version of Flushot+ is 1.52?  Thats interesting,
because I just downloaded a file called FLUSHOT2.ARC.  One wonders what
I've got.....(grin)  If you know, then let me in on it....  :-)

I keep trying to call his [Ross Greenberg's] BBS, but can never get a
connection.  I get connected, but thats all.  No "Enter your name...."
etc.  Perhaps someone can tell me my problem?  I'm calling from an
14.4K HST, 8N1, ANSI emulation and have (for his board) the baud rate
at 2400, &M0 and &K0.

                          James

Disclaimer:  I think, therefore I am.  I think.

------------------------------

Date:    Wed, 19 Apr 89 01:32:55 -0400
From:    Joe Sieczkowski <[e-mail]>
Subject: RE: Review of THE COMPUTER VIRUS CRISIS


>A more serious example is the suggestion that you can be exposed to a
>virus if you are on a net even if you practice "safe hex." While you
>may be exposed to a worm program if your computer is networked,
>viruses are not related to computer networks at all. A virus is a
>program that reproduces by modifying existing programs and files. A
>worm is a program that replicates itself through a network. The
>distinction can blur at times, and the term virus has been misused in
>the media so much that its technical meaning is seriously compromised
>(the Internet worm was originally reported as the Internet virus).
>
>Mark Paulk

Be careful here... "On a net" can mean various things.  Let's suppose
your PC is NFSed to some server that contains executable utilities.
Just because you practice "safe hex", it doesn't mean the guy who runs
the server does.  Hence, a utility that's a virus on the server can
infect your personal utilities.

Not only that, viruses can infect programs across networks as well as
worms can propogate through them.  The Internet situation was a worm
because the program propagated through Internet from machine to
machine.  It was not a worm merely because it existed on a network.
The program was self-contained and used utilies such as sendmail and
finger to spread.  If the program had modified the actual sendmail and
fingerd executables in such a way that they would in turn modify other
machines S&F executables, then it could be called a virus.

Joe

------------------------------

Date:    Wed, 19 Apr 89 10:36 EDT
From:    Roman Olynyk Information Services <[e-mail]>
Subject: Virus-handling Policies or Procedures at Mainframe Sites?

Our network node, a mixture of IBM & DEC mainframes, is currently
working on a procedure dealing with what should be done if a "virus"
is discovered on one of our systems.  Do any other sites have a
similar document that they could share with us?  Any suggestions will
be appreciated.

------------------------------

Date:         Wed, 19 Apr 89 13:38:47 EDT
From:         Peter Jaspers-Fayer <[e-mail]>
Subject:      CheckSum Methods of Virus Detection (PC)

We have evaluated CHECKOUT, a fairly comprehensive and carefully
thought-out method of detecting viral enfection by performing a
sequence of pseudo random-block checksums on the files that you
specify.  It comes with documentation and sample EXECs that show you
how to protect the program itself from "CHECKOUT-aware" viruses.  So
far so good, BUT:

No check is made of the BOOT sector.  Which brings me to the following
questions:

1) Does anyone have a similar program that DOES checksum the BOOT sector in
   several sections?

2) (this may be scatterbrained on my part, but) Is there a robust and
   'proper' way of overlaying a read-only, "invisible" file over top of
   the BOOT sector?  I've had a hack at this myself with a disk editor
   (figuring I could write the code in C later, if I can just see HOW to
   string things together...)

Answers to either, and even explanations as to why I'm thinking along
the wrong lines completely will be appreciated.

 /PJ
                     -------------------------------
'This system sure is user friendy!'
DMSSTT062E INVALID CHARACTER ''' IN FILEID ''THIS MODULE'.

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest             Thursday, 20 Apr 1989        Volume 2 : Issue 94

Today's Topics:
Viruses, Networks, and NFS: Questions
AppleShare volumes (Mac)
Forwarded: DenZuk Virus (PC)
Hiding Viruses by Intercepting Output

---------------------------------------------------------------------------

Date:    Thu, 20 Apr 89 07:58:06 PLT
From:    Joshua Yeidel <[e-mail]>
Subject: Viruses, Networks, and NFS: Questions

Joe Sieczkowski's recent remarks about the possibility of NFS-borne
viruses lead me to the following questions:

I understand that EXECUTING an infected program stored on an NFS
server could infect the client system.  I'm wondering if NFS has
loopholes such that a client can be infected by a server WITHOUT the
client requesting execution of a server-based program (for example,
via a worm process, a bogus remote procedure call, or ???)  Anyone who
knows NFS well is hereby invited to speculate.

We are a few weeks away from getting our first NFS machines, so I'm
not very familiar with the ins and outs (I don't have documentation
yet, either).  This is not a burning issue, just a question which our
security task force is bound to ask sooner or later.

------------------------------

Date:    Thu, 20 Apr 89 11:14 EST
From:    Roberta Russell <[e-mail]>
Subject: AppleShare volumes (Mac)

I have a question about virus infections on an AppleShare file server.

If I partition the server into two "volumes", and if one of these
volumes becomes infected, will that infection spread to the other
volume?  I'm not talking here about users infecting the other volume,
but about the infection spreading across the server from one volume to
another (users would have access to only one volume).  Since both
volumes share the same operating system, I'm assuming this would be
true, but would appreciate more informed opinions.  Thanks,

Robin Russell
Oberlin College Computing Center
prussell@oberlin (bitnet)
[e-mail] (internet)

------------------------------

Date:    Thu, 20 Apr 89 09:44:35 PDT
From:    [e-mail] (Rollo D. Rogers)
Subject: Forwarded: DenZuk Virus (PC)

Here are more details as a follow-up to the message i forwarded to you
yesterday on this suspected new virus. This person is seeking
assistance to find a way to eradicate the infection and perhaps
disassemble a copy of it too..
 -------
Forwarded mail follows:
Original-Date: Thu, 20 Apr 89 10:12:40 EST
Original-From: iuvax!bsu-cs.bsu.edu![e-mail] (Jeff Scott)

Here is some general information about the 'DENZUK' virus.  No
specific information is available as to it's origin, what it actually
does, or how long it takes to do it.

The 'DENZUK' virus.

    The DENZUK virus first started showing up here at Ball State
University, Muncie, Indiana around the 16th of April.  It was first
noticed because everytime that the computer is re-booted, a graphic
display will show up and the letters DEN ZUK * will slide in from the
sides of the screen. (The * is a graphics symbol resembling the AT+T
logo) then the system will roboot.  The display only lasts for about 3
seconds and will only be seen on a graphics screen (CGA is the only
one that has been checked).  If the disk is not write protected, the
virus (I call it that, but techincally it might be a worm, we really
don't know) will write a counter to the disk.  After about 5 times of
rebooting, the disk will become useless.  The information is still
there, but the disk is un-usable.  (It might overwrite the directory
blocks or something simular).

    The 'DENZUK' virus can be transfered to either other bootable
disks or DATA DISKS (unbootable disks).  It was thought for a while
that the virus could possibly be transfered to disks with a write
protect tab in (as it is possible to do that on IBM PC's), but this
can only be done in certain instances.  This instance would be if the
write-protect tab was squeezed or torn a bit.  The virus is transfered
to another disk whenever another disk is accessed (either read or
write) and that disk will then have the virus.

    The only way known of checking for that virus is to reboot the
computer with the disk you want to check in the A: drive.  This will
work with system or data disks to check for the virus.  This is not to
say that this is a sure- fire way of checking for DENZUK.  It may well
keep a counter to count up the number of times re-booted and not start
showing the display until a certain number.  That would give it time
to propagate even more.

    It has also been found out that the virus writes to the first
track.  This may be where the actual program is, or it could be where
the counters are kept, or both...

    At this point, we do not know what, if anything, this virus will
do to a hard drive.

    That is all that we know right now, if we learn any more I will
try to keep you informed.

Jeff Scott
Computer Competency
Ball State University

------------------------------

Date:    Thu, 20 Apr 89 16:06 EST
From:    <[e-mail]>
Subject: Hiding Viruses by Intercepting Output

        Some time ago, a person brought up the idea of a virus that
would intercept the sector reads.  If the sector that was read was the
one in which the virus lived, then the virus would return bogus data.
Someone else responded with a reason why this would not be an easy
task to do.  Could anyone tell me how this method of hiding a virus
would fail?  Consider the virus using this technique to be a boot
sector virus.

                                          John Wagner
                                          RITRC
                                          jww7917@ritvaxa

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest              Friday, 21 Apr 1989         Volume 2 : Issue 95

Today's Topics:
Administrative trivia
Reading the boot block (PC)
Virus disassemblies (PC)
Virus Cookbook for MS/PC-DOS (PC)
New document for anonymous FTP

---------------------------------------------------------------------------

Date:    Thu, 20 Apr 89 16:36:44 EDT
From:    [e-mail] (Kenneth R. van Wyk)
Subject: Administrative trivia

Just a bit of trivia for you all.  VIRUS-L turns 1 year old this
Saturday, April 22, 1989.  We're now up to about 1175 direct
subscriptions on the mailing list, and the comp.virus Usenet newsgroup
should be available shortly.

I think that, if nothing else, we've helped increase awareness.  That,
in itself, is progress.

Thanks everyone,

Ken

------------------------------

Date:    Thu, 20 Apr 89 20:32:42 CDT
From:    "Len Levine" <[e-mail]>
Subject: Reading the boot block (PC)

>From:         Peter Jaspers-Fayer <[e-mail]>
>Subject:      CheckSum Methods of Virus Detection (PC)
>
>No check is made of the BOOT sector.  Which brings me to the following
>questions:
>
>1) Does anyone have a similar program that DOES checksum the BOOT sector in
>   several sections?

The command:

debug <filetest.go >nul:

With the following contained in the file 'filetest.go':

- --- begin ---
L cs:1000 2 0 10
r cx
200
n c:\boot.blk
w cs:1000

quit
- --- end ---

will put the boot block into a file 'boot.blk'.  It uses the
system program debug.  I got this idea from the network from a
user Forrest Gehrke ([e-mail]).  Note that everything
from the 'L' in the first line to the 't' in 'quit' must be
included, especially the blank line before the 'quit'.  I used a
capital L for clarity, a lower case character works just fine.

The code does this:

  l cs:1000 2 0 10

This command will load the 10h sectors of the hard disk (2)
starting with sector 0 contiguously into memory starting at
location cs:1000.

  r cx
  cx:0000   (This is what the DEBUG will come back with.  That
             message will be lost if you use the >nul:
             command suggested.)
  :200      (You key in the 200  for the number of bytes
             you want to write).

  n d:\foo   (Naming filename FOO on drive d:)

  w cs:1000 (Write starting at address cs:1000)
            DEBUG will respond with a message saying it is writing
            200 bytes. That message will be lost if you use the
            >nul: command suggested.

  q         (quit DEBUG)

Any errors that I made are of course my own, not his.  The file
'boot.blk' can then be tested by the usual means.

Note that a virus that affects every read made from the disk,
detects an attempt to read the boot block, and passes you a copy
of the good boot block instead of the infected one, will defeat
this.  If so, a very well written virus was encountered.

+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
| Leonard P. Levine               e-mail [e-mail] |
| Professor, Computer Science             Office [phone] |
| University of Wisconsin-Milwaukee       Home   [phone] |
| Milwaukee, WI 53201 U.S.A.              Modem  [phone] |
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +

------------------------------

Date:    Thu, 20-Apr-89 17:11:42 PDT
From:    portal!cup.portal.com![e-mail]
Subject: Virus disassemblies (PC)

Earlier this month, Jim Goodwin gave me a file containing numerous
virus disassemblies and asked me to forward it to the researchers
subscribing to VIRUS-L.  I consulted with Ken van Wyk on this, knowing
that the distribution of virus disassemblies is a rather sensitive
issue.  Ken graciously offered to allow Jim to post a message to
VIRUS-L describing his virus disassemblies and explaining how to
contact him to obtain them.  The following is Jim's message:

 ---- start of forwarded message ----
Original-Date: 04/19/89 12:03:15
Original-From: JIM GOODWIN

Mr. van Wyk: I appreciate your position on the distribution of
disassembled viruses, and while we differ somewhat in our opinions on
this issue, it was very gracious of you to express your respect for my
own position.  I think we can gain a great deal from a detailed
analysis of existing viruses, both from an antiviral development
standpoint and from a psychological standpoint.  Much can be discerned
about the nature of a perpetrator's mind from an analysis of his code.
I have just finished the disassembly of the 1704 virus, for example,
and can now tell you quite a bit about the perpetrator of this virus.
The virus was surprising in a number of respects.  It has two levels
of encryption, which made it extremely difficult to disassemble, and
it has the most advanced activation mechanism I have yet seen in a
virus. The activation involves randomizations, tests for machine
types, tests for clock types and screen types, date checks and a host
of other parameters.  It is also the first virus I've come across
that will NOT infect a true IBM PC.  It will only infect clones.  The
code to test for the true blue IBM machine was quite simple, and
follows:

.     (Checks copyright at ROM address 0F000:0E008H)
.     MOV   CS:[BX+DS:161H],AX
.     MOV   CS:[BX+DS:163H],ES
.     MOV   AX,0F000H
.     MOV   ES,AX
.     MOV   DI,0E008H
.     CMP   WORD PTR ES:[DI+6], 4249H   ; Check 'IB'
.     JNZ   A_CLONE
.     CMP   WORD PTR ES:[DI+8],4DH      ; Check 'M'
.     JZ    KILLVIRUS

In spite of some creativity and ingenuity within this virus, there
were some telltale signs of a programmer that had done little "system
level" programming before.  The virus, for example, cannot infect any
file greater than 64K in size, and is unable to infect EXE files (only
COM files).  There is nothing inherent in the virus architecture to
prevent it, it simply appears that the designer was unfamiliar with
EXE header formats and felt uncomfortable with segment register
manipulations for large files.  Also, the designer's use of interrupts
1C and 28 appear to be very inefficient.  In spite of this, the virus
is effective at identifying itself (through an interrupt 21 link) and
avoiding conflicts with other memory resident processes. The telltale
key to the sophistication level of the programmer, however, was the
use of interrupt 21 for the infection process.  Using this interrupt,
almost any virus protection product will be able to stop it or detect
it.  We tried a number of products against it and they all worked,
even Flu-shot+, which is able to catch only the crudest of viruses.
So the designer was apparently unfamiliar with I/O techniques that
would avoid filter detection.  All in all it is quite a schizophrenic
virus.

In any case, I thank you for the opportunity to post this message
telling everyone that my virus disassembles (12 to date) are available
to select researchers.  They may obtain them by calling Mr. McAfee's
Homebase Virus board at 408 988 4004 and leaving me a message.

I have read, by the way, the Virus-L message log (provided by Gary
Tom) and found it of interest.  It seems that the work you folks are
doing meshes well with the research done by Mr. McAfee and his team in
California. They have been very helpful in logging infection
occurrences and collecting live viruses.  The Sentry program by Mr.
McAfee has also been invaluable in the collection process and should
be used by any team that is attempting to "trap" viruses in a large
host collection base (we have it in over 6,000 systems now and it has
caught us a total of 31 new viruses).  He has just made the program
public domain so there's no excuse for anyone not to use it.

I would also like to take this opportunity to thank Gary Tom for his
tireless assistance in forwarding information between us.

If I can be of any assistance in explaining any of the material that
you already have, then please feel free to contact me.

Jim Goodwin  From the Homebase Virus BBS

408 988 4004

 ---- end of forwarded message ----

I am mailing John McAfee's Sentry program to Ken in uuencoded ARC
format so that it can be considered for addition to the
lll-winken.llnl.gov and LISTSERV archives.  It is available for
downloading from John's Homebase BBS.  John also has a virus message
section on his BBS that he has recently opened up for public access;
VIRUS-L subscribers are invited to call up his BBS and check it out.

Gary Tom, Tandem Computers Inc., Cupertino, CA
[e-mail]
sun!portal!cup.portal.com!garyt

[Ed. Sentry is now on lll-winken.llnl.gov for anonymous FTP in the
file ~ftp/src/pc/sentry.arc.  Thanks!]

------------------------------

Date:    19 April 89, 10:43:20 EDT
From:    <[e-mail]>
Subject: Virus Cookbook for MS/PC-DOS (PC)

I have a problem. I would like to modify the behavior of a .EXE file
to solve it. I believe that the techniques for doing this are the same
as those which a virus might employ in its effort to infect such a
file.  "Infecting" .COM files is simple enough, but the particular
program I would like to modify is a .EXE file.

The program is TELIX, a pretty good little shareware communications
program which, to my constant irritation, does not support F11 and F12
on the enhanced keyboard. I can write the patch to fix the keyboard
problem, but I don't know how to infect the .EXE file with the
solution.

If one of you kind folks could tell me how a virus program propagates
itself to a .EXE file, I promise not to use the information for
unscrupulous purposes. (I'm not a mad scientist. I just want to
install a patch.)

                            Hopefully,
                            Jeff Clough

Programmer for the august body of the Computer
Center of Georgia State University.
[e-mail] or 404-651-4537.BELLNET

------------------------------

Date:    Fri, 21 Apr 89 08:38:12 EDT
From:    [e-mail] (Kenneth R. van Wyk)
Subject: New document for anonymous FTP

I've just placed the following virus paper on lll-winken.llnl.gov for
anonymous FTP:

Developing Virus Identification Products
by Tim Sankary

The filename is ~ftp/virus-l/docs/identify.txt.  Thanks, Mr. Sankary.

Enjoy,

Ken

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest              Friday, 21 Apr 1989         Volume 2 : Issue 96

Today's Topics:
re: Hiding Viruses by Intercepting Output
McAfee's SENTRY a-v software (PC)
re: Virus disassemblies (PC)

[Ed. I apologize for sending out such a short digest; we're testing a
mail<-->news gateway and need something to feed it.]

---------------------------------------------------------------------------

Date:    21 April 1989, 08:51:33 EDT
From:    David M. Chess  <[e-mail]>
Subject: re: Hiding Viruses by Intercepting Output

> Could anyone tell me how this method of hiding a virus
> would fail?

The "Brain" virus (I think it is) does something very much like
this.   It fails when a user who is checking out an infected
diskette does the checkout on a *clean* system, in which the
virus hasn't gotten control.   Another illustration of how
important it can be to get your system into a known clean
state before doing virus-scanning.                  DC

------------------------------

Date:    FRI APR 21, 1989 11.47.23 EST
From:    "David A. Bader" <[e-mail]>
Subject: McAfee's SENTRY a-v software (PC)

I just had the chance to try out John McAfee's Sentry Anti-viral
software for the PC, and frankly - it is worthless.  I followed the
instructions on installation, and it automatically places itself in
autoexec.bat and reboots (maybe John, you could have told me that you
were going to modify my file, or that you would do a cold boot - for
me, it matters.)  Anyway, After Sentry did a check of filesize and a
random checksum at the beginning, middle, and end of every file on my
harddisk, it told me nothing.  Ok, so I run Sentry a second time just
to see what happens and I get told my interrupt vectors have changed
and I should contact someone because that could mean a virus.  Have you
ever heard about FASTOPEN, or FluShot Plus, or one million other
programs that I give permission to to take over my interrupt vectors?
You could at least scan the memory tables and tell me who the owner of
the interrupt vectors is.  And then, after taking a minute to scan all
my files, I would appreciate "XXXXX file changed since last use" - NOT
"3 files were modified".. Useless, John, absolutely useless.

            -I'm sticking with FluShot Plus!
              -David Bader
               DAB3@LEHIGH

------------------------------

Date:    21 April 1989, 14:06:08 EDT
From:    David M. Chess   <[e-mail]>
Subject: re: Virus disassemblies (PC)

Some comments on Jim Goodwin's comments.

>                       It is also the first virus I've come across
> that will NOT infect a true IBM PC.  It will only infect clones.  The
> code to test for the true blue IBM machine was quite simple, and
> follows:

If you'll look carefully at that code, you'll notice a bug; the last
compare should be a BYTE compare, not a word compare.  As it is, it's
testing for "IBM" followed by a byte of 00.  Even True Blue IBM BIOSs
don't have that, so in fact it will work identically on IBMs and
clones.  (Either the virus writer didn't have a real IBM to test on,
or he's intentionally trying to confuse us!)  So it *will* infect a
true IBM PC (I've tested it).

The two levels of encryption are just a couple of XORs; one simple way
to crack most of it is to let it run (on a machine with no hard disks,
of course!) up to the point where it has finished descrambling itself,
and then dumping the descrambled code to disk and killing the
execution.

COM and EXE files: The only virus that I know of that will infect both
is the Jerusalem.  The only other virus that I know that will infect
EXE files is the EXE flavor of the April 1st Israeli virus.  All the
others I know of are either COM or boot infectors.  Do you know of
other EXE infectors?  I'm sure the list would be interested.

All the COM and EXE infectors that I know of use INT21 to do their
infecting.  Do you know of some that don't?  It's possible in theory
of course, but I've never seen one.  Again, I'm sure the list would be
interested.

> we have it in over 6,000 systems now and it has
> caught us a total of 31 new viruses.

Wow!  Only about 14 or 15 (counting liberally) PC-DOS viruses have
been reported on this list.  Do you have capsule summaries of the
viruses you've found?  (Or does that 31 perhaps include viruses for
other operating systems, or perhaps some non-virus Trojan horses?)

Sounds like you've got a gold mine of information, there!  I'll
attempt to check out the BBS myself.

Dave Chess
Watson Research

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest              Monday, 24 Apr 1989         Volume 2 : Issue 97

Today's Topics:
Worms and Trojan Horse talk at NETCON.
Request for guest speakers.
Re: McAfee's SENTRY a-v software (PC)
Congress catches the computer virus bug...
Using Checkfunctions For Virus Detection (General Interest)
BALL VIRUS (PC)

---------------------------------------------------------------------------

Date:    Fri, 21 Apr 89 18:52 EDT
From:    John McMahon - NASA GSFC ADFTO - <[e-mail]>
Subject: Worms and Trojan Horse talk at NETCON.

Conference Announcement:

        NETCON 1989 - A meeting of BITNET users in Baltimore, Maryland
        during Memorial Day weekend will feature the following speakers
        during the Saturday technical sessions:

                David Bolen - Speaking on the XYZZY utility

                Valdis Kletnieks - Speaking on RELAY Version 2

                John McMahon - Speaking on Worms, Trojan Horses and
                               Computer Networking.

        For further information contact Reba Taylor at [e-mail]
        and Joe Ogulin at [e-mail]


I figured that was a good way to plug my upcoming talk at NETCON 1989.

For those of you who are curious, "Worms, Trojan Horses and Computer
Networking" will be an hour (or so) long talk where I will be doing a
novice level review of three networking "events".

        The CHRISTMAS EXEC Trojan Horse (and similar) on BITNET,
        The Father Christmas Worm on SPAN/HEPNET,
        and (of course) the Morris Internet Worm.

I plan to point out during my talk that BITNET is beginning to coexist
with other networks (e.g. JNET over SPAN & HEPNET, BITNET2 over
NSFnet) and that an "attack" on another network can affect BITNET.

Similarly, I am going to talk a bit about "the costs" that a worm
attack can incur.  Costs in wasted time, personnel, network resources
and the legal costs.  Obviously I want to discourage this kind of
foolishness (worms), my machine is on several networks!

If you are interested in attending, or wish to learn more about
NETCON, please contact Reba Taylor at REBAT@VTVM1 and/or Joe Ogulin at
[e-mail]

Any questions/suggestions/comments about my talk can be directed to me...
+------------------------------------+-----------------------------------+
|John "Fast Eddie" McMahon           |Span: SDCDCL::FASTEDDY (Node 6.9)  |
|Advanced Data Flow Technology Office|Arpa: [e-mail]|
|Code 630.4 - Building 28/W255       |Bitnet: FASTEDDY@DFTBIT            |
|NASA Goddard Space Flight Center    |GSFCmail: JMCMAHON                 |
|Greenbelt, Maryland 20771           |Phone: x6-2045                     |
+------------------------------------+-----------------------------------+

------------------------------

Date:    Sat, 22 Apr 89 16:12 EST
From:    Space, the final frontier.... <[e-mail]>
Subject: Request for guest speakers.

     I've been recently elected secretary of the Xavier University
chapter of the ACM and I'm sending out a request for guest speakers on
the subject of viruses/worms/trojan horses for the fall semester of
this year.  If anyone is interested or knows of someone that would be
interested, please contact me.  My address is [e-mail].

Thanks in advance,

Tom Kummer

------------------------------

Date:    Sat, 22-Apr-89 13:20:56 PDT
From:    portal!cup.portal.com![e-mail]
Subject: Re: McAfee's SENTRY a-v software (PC)

In VIRUS-L #2.96, David Bader writes about John McAfee's SENTRY
anti-viral program, and concludes that "frankly --it is worthless."  I
tried SENTRY myself before forwarding it to the VIRUS-L moderator, and
I'd like to try to address David's concerns.

David states:
> I followed the instructions on installation, and it automatically
> places itself in autoexec.bat and reboots (maybe John, you could have
> told me that you were going to modify my file, or that you would do a
> cold boot - for me, it matters.)

The SENTRY.DOC installation instructions state:

    "The SENTRY installation will re-boot your system and then begin
  its logging function.  It will create a log file called SENTRY.LOG
  and store it at the root of your boot disk.  It will then install
  the SENTRY check routine at the root of your boot disk and include
  it as the first program in your autoexec.bat routine.  SENTRY.COM
  MUST REMAIN THE FIRST INSTRUCTION IN YOUR AUTOEXEC IN ORDER TO
  OPERATE CORRECTLY."

In addition, the SENTRY installation program prints a message that it
is "Ready to re-boot this system," warns the hard-disk user to remove
any floppy disks, and prompts for a key-press before automatically
re-booting.  I thought the instructions and the program messages were
clear enough about what would happen during installation. I was only
surprised that installation took much less time than I thought it
would, knowing that the program had to scan the entire disk directory
and examine every executable file.

> Anyway, After Sentry did a check of filesize and a random checksum
> at the beginning, middle, and end of every file on my harddisk, it
> told me nothing.

After its initial installation, there is nothing to tell.  David might
have misunderstood the purpose of SENTRY.  It assumes that you start
with a virus-free system environment, and attempts to detect viral
infections by warning you of changes in that environment.  The
installation process does not look for pre-existing viruses, so no
messages about them are printed.

> Ok, so I run Sentry a second time just to see what happens and I get
> told my interrupt vectors have changed and I should contact someone
> because that could mean a virus.  Have you ever heard about
> FASTOPEN, or FluShot Plus, or one million other programs that I give
> permission to to take over my interrupt vectors?

As emphasized in the installation instructions, SENTRY must be run as
the first program in AUTOEXEC.BAT (that is, immediately after booting
and loading CONFIG.SYS drivers) in order to work correctly.  The
interrupt vectors and programs are checked against the log at that
time.  If they match, then after that it doesn't matter which of those
programs you load or what interrupt vectors they use -- they should
all be free of viruses.

> ... And then, after taking a minute to scan all my files, I would
> appreciate "XXXXX file changed since last use" - NOT "3 files were
> modified".  Useless, John, absolutely useless.

This comment baffles me.  My experience has been that whenever SENTRY
finds a changed file, it stops, displays the filename and a message
about what has changed, and then waits for the user to press a key.
For example:

   WARNING - The file C:\UTIL\LIST.COM has different time.
   A VIRUS INFECTION MAY HAVE OCCURRED
   PLEASE SEE THE SENTRY USER MANUAL FOR INSTRUCTIONS

   PRESS ANY KEY TO CONTINUE

Only at the end of its checking does it print a summary line:

   250 files checked.  1 changes detected.

Perhaps David is using an older version of SENTRY, not the one that I
sent to Ken.  In any case, I hope that David's unhappy experience does
not dissuade interested parties from trying the program out for
themselves.

For me, SENTRY offers a good combination of safety (provided by early
detection of possible infections), convenience (automatic checking
whenever the machine is booted), compatibility (no interrupt vector or
memory buffer conflicts), and performance (checking is fast,
re-installation is fast, and since it is non-resident, it does not
take cpu cycles or memory away from other programs).  It's true that
SENTRY does not prevent viral infections from occurring, nor does it
remove viral infections once they have occurred.  As a tool for
quickly detecting new viral infections, however, I find it to be far
from "useless."

Gary Tom
[e-mail]
sun!portal!cup.portal.com!garyt

------------------------------

Date:    Sun, 23 Apr 89 14:45:08 EST
From:    [e-mail]
Subject: Congress catches the computer virus bug...

I received the following message from the internal security conference
at MITRE.  I thought others here might have some observations on
this...

David Gursky
Member of the Technical Staff, W-143
Special Projects Department
The MITRE Corporation

 ------- Forwarded Message

Forum-Transaction:  [0753] in the >site>forum_dir>bb meeting
Transaction-Entered-By:  [e-mail]
Transaction-Entered-Date:  24 Feb 89 16:42 EDT

The Senate Judiciary Committee is holding a public hearing on viruses on
Tuesday, 28 February 1989, in Room 226 of the Dirksen Senate Office
Building from 1000 to 1300. I have not heard who is going to testify,
but I assume it is preliminary to any vote on the Virus Eradication Act
of 1989.  Larry.

[Ed. Meeting delays deleted...]

======================================================
Forum-Transaction:  [0755] in the >site>forum_dir>bb meeting
Transaction-Entered-By:  [e-mail]
Transaction-Entered-Date:  28 Feb 89 10:36 EDT

I have commented on the draft of HR 55 as of 1/27/89, and it is
essentially similar in wording to Al's citation, except that I believe
it now invokes a maximum penalty of 20 years.

Be that as it may, I believe much work is needed on the wording: for
instance, it appears that to me that the Internet Worm would not have
been illegal if it had functioned as intended: a one-time surreptitions
invasion, and low-level reproduction.
=======================================================
Forum-Transaction:  [0756] in the >site>forum_dir>bb meeting
Transaction-Entered-By:  [e-mail]
Transaction-Entered-Date:  1 Mar 89 08:30 EDT

Thanks, Mike, for the update.  Of particular concern to me in the bill
is that it doesn't seem to do a good job of defining precisely what is
illegal.  Based on the '88 text, it seems clear that if I give you a
program that I know has a bug in it, and don't tell you, I'm guilty
under this bill.  (Granted, I should not have given you a program with a
known bug without telling you, but I really don't think that that was
what the bill's authors had in mind.)  What's worse, I'm not sure I'm
safe from prosecution if I give you a text editor/word processing
package that works properly!

(Why do I say that?  Because every text editor/word processor I know of
has commands that can cause "damage" - by deleting things!  Thus, the
case comes down to a question of whether or not I "told" you about the
damage that can be done by using the delete commands.  I've seen a lot
of documentation that did NOT have big red warning signs all over the
place, warning people about what can happen.  And then, of course, since
DOS has a command that will let me format my hard disk, and that's not
well documented at all, maybe we can start going after people big time.
A felony for shoddy documentation!)

(Of course, one can defend against prosecution by claiming that the text
editor /word processor/operating system did in fact contain
documentation describin
 what could happen if the user wasn't careful.  But then, so could the
writer of a "real virus".  After all, if one ran the executable file
through a debugger before execution, one would see the ASCII strings
identifying the file as a virus, and warning that executing it would be
hazardous to one's health.)

                                        Al

NOTE:  THE ABOVE OPINIONS ARE MINE.  MINE AND NOBODY ELSE'S.  UNDER NO
CIRCUMSTANCES SHOULD THEY BE INTERPRETED AS REPRESENTING ANYBODY ELSE -
OR ANY ORGANIZATION, WHETHER I WORK FOR IT OR NOT!!  ON TOP OF THAT, I
AIN'T NO LIARYER, JUST A PLAIN AND HUMBLE LAYMAN WHAT SPEAKS UP OUT OF
TURN ON OCCASION.

[Ed. More meeting delays...]
 ------- End of Forwarded Message

------------------------------

Date:    Sun, 23 Apr 89 16:53:37 EST
From:    [e-mail]
Subject: Using Checkfunctions For Virus Detection (General Interest)

I've been going through the Virus-L archives doing some background for
my work on viruses here at MITRE.  I'm up to late June of last year,
when there was a strong debate about the merits of using a
checkfunction to detect the presence of viruses in applications.  To
remind everyone, the consensus at that time was that using a
checkfunction in such a manner would only be effective against the
simplest of viruses, that an advanced virus would be resiliant against
detection in such a manner.

I believe it is possible to use a checkfunction in a constructive
manner to detect even the most advanced computer viruses, and it
involves a technique called a "cryptographic checkfunction".

In a normal checkfunction, your have an arbitrarily long string x
(which is really an application) that you apply to function [f(x)]
that results in the value for your checkfunction value.  A
cryptographic checkfunction adds an addition function [lets call it
q(x)] that encrypts an arbitraily long string.  Instead of making the
result of f(x) being the checkfunction value, the result of f(q(x)) is
the checkfunction value.  Any foreign data (z) inserted into x would
not only have to take into account how the checkfunction [f(x)]
operates, but how the encryption algorithm [q(x)] operates.  This task
can be made even more difficult by choosing a key for q(x) that is
dependent upon x itself.

[In other words, suppose your have the string X1 X2 X3 X4.  You apply
this string to q(x) and the result is Y1 Y2 Y3 Y4.  Now suppose you
have a virus string Z1 Z2 that inserts itself into X1... so you now
have (for instance) X1 X2 X3 Z1 Z2 X4.  The result of applying this to
q(x) would be something like Y1 Y2 Y3 A1 A2 A3, instead of Y1 Y2 Y3 A1
A2 Y4.]

A problem with this is key-dependent encryption algorithms are not
exactly speed demons, but the new generation of microprocessors may
have the horse- power for them to be used effectively.  Comments
anyone?

David Gursky
Member of the Technical Staff, W-143
Special Projects Department
The MITRE Corporation

------------------------------

Date:    Mon, 24 Apr 89  14:23:12 TST
From:    Koyun@TRBOUN
Subject: BALL VIRUS (PC)

    HI!
    I HAVE AN IBM PC-XT COMPATIBLE.  LAST DAY WHEN I LOOKED FOR A
PROGRAM I SEE THAT ONE OF MY PROGRAM WAS DESTROYED.THERE WAS A BAD
CULSTER ON IT.  WHEN I TRY TO VERIFY HARDDISK SUDDENLY A BALL OCCURED
AND BEGAN TO HIT BORDERS AND LETTERS,AND WHEN I TRY TO VERIFY IT
OCCURS AGAIN.
    IF SOMEBODY KNOW ANYTHING ABOUT THIS VIRUS OR HAVE AN INJECT,PLEASE
SEND ME .
    MY ADRESS IS  [e-mail]
    THANKS.....
                      TAN KOYUNOGLU
                      BOSPHORUS UNIVERSITY

------------------------------

End of VIRUS-L DigestVIRUS-L Digest              Monday, 24 Apr 1989         Volume 2 : Issue 98

Today's Topics:
Re: CheckSum Methods of Virus Detection (PC)
re: Information wanted on "Stoned" virus (PC)
Write protecting a hard disk (Mac)
Virus papers (finally) available on Lehigh LISTSERV

---------------------------------------------------------------------------

Date:    Mon,  24 Apr 89 15:37:13 +0200
From:    Y. Radai <[e-mail]>
Subject: Re: CheckSum Methods of Virus Detection (PC)

  Peter Jaspers-Fayer (in Issue 93) mentioned that CHECKOUT does not
checksum the boot sector.  It's strange, but despite the abundance of
boot sector viruses, few checksum programs are any better in this
respect than CHECKOUT.  In fact, of the over 20 such programs I have
heard of for the PC, none of the freeware/shareware ones and not too
many of the commercial ones checksum the boot sector.

  And even of those who are aware of the need to checksum the boot
sector in addition to files, most seem to miss the fact that the
*partition record* also contains code which is executed when booting
from a hard disk.  And there's at least one virus (the "Stoned" or
"Marijuana" virus, which apparently originated in New Zealand) which
exploits this fact.  Note, by the way, that Len Levine's method (in
Issue 95) of copying the content of the boot block to a file won't
work in the case of the partition record since DEBUG can't access it.

  Concerning Len's solution for the boot block, he writes:
>Note that a virus that affects every read made from the disk,
>detects an attempt to read the boot block, and passes you a copy
>of the good boot block instead of the infected one, will defeat
>this.

  But that's only if the virus is already in memory.  You can avoid
this problem by running the checksum program immediately after cold
booting from a system which is known to be clean (as was mentioned
recently by David Chess).

                                          Y. Radai
                                          Hebrew Univ. of Jerusalem

------------------------------

Date:    24 April 1989, 11:26:40 EDT
From:    David M. Chess   <[e-mail]>
Subject: re: Information wanted on "Stoned" virus (PC)

Tom Sheriff asked about this virus back on 4/17.  I've seen it, and
done a certain amount of analysis.  It seems to infect both floppies
and hard disks.  It captures INT13, and uses that to try to infect any
floppies read or written in drive A: (BIOS 00).  If an infected floppy
is used to boot a machine with a C: drive (BIOS 80), the c: drive will
become infected.  If an infected floppy is booted at just the right
time (it tests the system clock), the message (or at least the first
sentence) is displayed on the screen before the boot occurs.  The
message will not be displayed when booting from an infected hard disk.

The virus is rather lazy, and uses hard-wired locations to store the
original boot record.  So it will overlay possibly-in-use tracks when
it infects a new disk or diskette.  That's the only "destructive"
behavior that I saw.  It makes no attempt to hide, and an infected
boot record can be visually identified by the presence of the message.
Automatic programs that watch for changes to boot sectors should have
no trouble spotting it, either.

Usual disclaimers: the virus that I'm describing here may not be the
same one you're infected with!!  Get a guru to analyze yours
thoroughly before deciding that you're clean.  (If it *is* the same
one I've seen, it'll be pretty simple to analyze...)

Dave Chess
Watson Research

------------------------------

Date:    Mon, 24 Apr 89 15:21:50 EDT
From:    "Gregory E. Gilbert" <[e-mail]>
Subject: Write protecting a hard disk (Mac)

Is it possible to lock a Macintosh hard disk so as to protect it from
an infection?

------------------------------

Date:    Mon, 24 Apr 89 15:32:19 EDT
From:    [e-mail] (Kenneth R. van Wyk)
Subject: Virus papers (finally) available on Lehigh LISTSERV

After much prodding, I've placed most of the virus papers that we've
accumulated on the [e-mail].  BITNET users can now
obtain these files from LISTSERV (please don't send your requests to
the list - it won't work).  Note that the series of reports on the
Internet worm are not included on the LISTSERV, primarily for reasons
of size (most of them exceed the BITNET limit of 300000 characters, as
stated in the BITNET Usage Guidelines).

These files, as with the ones on lll-winken.llnl.gov, are also
accessible via anonymous FTP to IBM1.CC.Lehigh.EDU.

Also, I was asked to include a description (or abstract) of each of
the documents.  Here is what I have (along with filenames in CAPS), in
no particular order:


"Coping with Computer Viruses and Related Problems"
                by Steve R. White, David M. Chess, and Chengi Jimmy Kuo
                   of IBM
                January 1989
                LISTSERV Filename: IBM PAPER

ABSTRACT: We discuss computer viruses and related problems.  Our
intent is to help both executive and technical managers understand the
problems that viruses pose, and to suggest practical steps they can
take to help protect their computing systems.



"Developing Virus Identification Products"
                by Tim Sankary
                Copyright (c) 1989, all rights reserved.
                (April) 1989
                LISTSERV Filename: IDENTIFY TXT

DESCRIPTION: This paper presents techniques for virus identification.



"Net Hormones"
                by David S. Stodolsky, PhD. of Copenhagen University
                Copyright (c) 1989, all rights reserved.
                March 1989
                LISTSERV Filename: HORMONES NET

ABSTRACT: A new type of infection control mechanism based upon contact
tracing is introduced. Detection of an infectious agent triggers an
alerting response that propagates through an affected network. A
result of the alert is containment of the infectious agent as all
hosts at risk respond automatically to restrict further transmission
of the agent.  Individually specified diagnostic and treatment methods
are then activated to identify and destroy the infective agent. The
title "Net Hormones" was chosen to indicate the systemic nature of
this programmed response to infection.



"Computer Viruses: A Rational View"
                by Raymond M. Glath of RG Software Systems, Inc.
                April 1988.
                LISTSERV Filename: VIRUS GLATH

DESCRIPTION: This paper presents an overview of viruses and associated
terminology.  It examines such topics as how one might become infected
by a virus, and what to do if one does become infected.  It also sets
guidelines for virus prevention and removal.



"The Infection of PC Compatible Computers"
                by Stephen E. Kiel and Raymond K. Lee of Georgia Tech
                Summer 1988.
                LISTSERV Filename: VIRUS KIEL

DESCRIPTION: The recent publicity over computer viruses has produced
mixed reactions and much confusion inside, as well as outside, of the
computing industry.  The conflicting opinions are caused either by a
misunderstanding of what viruses are or a lack of understanding of
their potential problems.  This paper answers those questions and in
addition, gives a description of currently suggested methods for IBM
PC's and compatibles for detecting, preventing, and eliminating
viruses.  A highly technical discussion is not the objective, but
rather a broad overview is given along with sources of additional
information and assistance.



"Potential Virus Attack"
                by L. P. Levine of University of Wisconsin-Milwaukee
                September 1988
                LISTSERV Filename: VIRUS LEVINE

DESCRIPTION: This paper examines the vulnerability to viruses of Dr.
Levine's computing environment and suggests methods for reducing its
risk.



"Virus 101" (Chapters 1-4)
                by George Woodside
                March 1989
                LISTSERV Filenames: V101 1   V101 2   V101 3   V101 4

DESCRIPTION: This series of papers present an in-depth look at
viruses, in the form of a virus "course" of four chapters.  Note that
many of the author's statements are specific to his ATARI ST.


Enjoy,

Ken

------------------------------

End of VIRUS-L Digest
*********************VIRUS-L Digest             Tuesday, 25 Apr 1989         Volume 2 : Issue 99

Today's Topics:
Password protection based virus prevention
FLU_SHOT+ Effectiveness (PC)
Virus Info Request (PC)
Flu_Shot availability (PC)
Review of COMPUTER VIRUS CRISIS
Powering down before using a micro

---------------------------------------------------------------------------

Date:    Mon, 24 Apr 89 16:41:27 EDT
From:    "Gregory E. Gilbert" <[e-mail]>
Subject: Password protection based virus prevention

One way of helping prevent a virus infection is "password based access
control" How does this help?  I assume I have to enter a password to
be able to work on my micro.  I don't see how this helps, because as I
understand it viruses usually do there most damage while the micro is
in use.  Sooner or later I will have to use the micro; I am not
worried about protecting my micro from people I don't know maliciously
infecting my micro as a personal vendetta.  If I did not explain the
question sufficiently please feel free to contact me.


[Ed. A password for access control (such as on a PS/2), could help in
obtaining some level of physical security, by preventing unauthorized
persons from starting up a PC without the consent of the owner.  Also,
passwords don't have to be limited only to access control, at least in
this sense.  A password could conceivably be used to enter an
"administrator mode" during which executable files could be installed
and altered, but not executed.  During a normal "user mode",
executables could not be altered or installed, only executed.  If this
were sufficiently supported in hardware, it could reduce one's risk,
imho (in my humble opinion).  Indeed, it is very similar to the way in
which most multi-user systems work.]

------------------------------

Date:    Tue Apr 25 01:17:51 1989
From:    utoday![e-mail]
Subject: FLU_SHOT+ Effectiveness (PC)

>..even FLU_SHOT+, which catches only the crudest of viruses...

Harumpf, I say, Harumpf!

Maybe I'm a little biased, but I think that my FLU_SHOT program
catches a vast majority of the viruses out there in the MS-DOS world.
There are ways around it, of course, just as there are ways around
*any* anti-virus software.  But, at least the method of distribution
(shareware) allows a person to use the product for evaluation purposes
before having to spend a penny.

PCMag found it worthwhile enough around real viruses and a virus
simulator to give it their Editor's Choice Award.

Ross M. Greenberg, Author, FLU_SHOT+

------------------------------

Date:    Tue Apr 25 01:24:24 1989
From:    utoday![e-mail]
Subject: Virus Info Request (PC)

I would like to request that anyone finding a new virus send me as
much information as possible on the virus, including reach information
(such as address and telephone number) so a disassembly can be
attempted.

I will do two things with this info: 1) enhance FLU_SHOT as required
to deal with it and 2) I'll prepare a report for the list on how the
virus works, and how to protect against it.

Ross

------------------------------

Date:    Tue Apr 25 01:09:46 1989
From:    utoday![e-mail]
Subject: Flu_Shot availability (PC)

For Access to FLU_SHOT:
             RamNet BBS:  (212)-889-6438  (Free)
             CompuServe, PCMagNet         (Free Signup, download @ $12/hr)
             BIX                          ($39/quarter)
             SimTel-20                    (Free, current version available)

Due to the code winning PCMag's Editor's Choice, my own BBS has been
extra busy of late (averaging 26 seconds between calls!).  As such,
I'm happy to send the first 100 VIRUS-L readers sending me a letter
mentioning VIRUS-L, along with all their appropriate reach information
(name, address, etc) a copy of the code @ no charge.

It's shareware, so even if you opt to not register it, feel free to
pass it around to others.  I'd prefer that you [eventually] register
it, of course, and at least let me know what your comments and
suggestions for the next version might be.

My turnaround time is getting pretty good, averaging three days.
Here's my address:
      Ross M. Greenberg
      Software Concepts Design
      594 Third Avenue
      New York, New York  10016

(For those who do get through to my BBS (at 2400/1200/N/8/1), hit a
return, then stick in some sort of unique handle and password until
you get a "Welcome New User" message.  Then pop over to [A]rea 2 and
download FSP_152.ARC.  )

Ross M. Greenberg, Author FLU_SHOT+

[Ed. The above message went back and forth between Ross and myself a
couple of times...  I didn't want for it to be a commercial
advertisement.  I hope that it's toned down enough now that it can be
read as a notice of availability, and nothing more.

How about someone sending in an independent, objective review of this
latest version of Flu_Shot+?]

------------------------------

Date:    Tue, 25 Apr 89 10:16 EDT
From:    "J. D. Abolins" <[e-mail]>
Subject: Review of COMPUTER VIRUS CRISIS

Another inaccuracy in the book is in the way it treats the Hebrew
University case. The authors of the book went for the theory that the
virus as politically motivated. They use the case as an example of how
viruses can be used by terrorists. I checked for the references the
authors used for the case, the bibliography gives only one specific
reference. (Also the designation used for this virus case was "the PLO
virus" which further emphasizes the political origins claim.)

It was the treatment of this case that made me look at the book more
carefully.

------------------------------

Date:    Tue, 25 Apr 89 13:48:08 EDT
From:    "Gregory E. Gilbert" <[e-mail]>
Subject: Powering down before using a micro

Many articles on virus prevention reccomend turning off a micro before
using it.  If the micro has a hard disk, what good does this do?

------------------------------

End of VIRUS-L Digest
*********************